[Feature]: discord-app read-only channel navigation and forum/thread support

[ByteYue]

Feature Description

The discord-app adapter can currently read messages from the active Discord channel, and it can list servers/channels. It would be useful to add read-only channel navigation and channel-targeted reads so automation can safely collect messages from a small set of selected Discord channels without sending messages.

Related improvements that would make this robust:

• Include stable channel metadata in discord-app channels output, especially guild_id, channel_id, url, and channel type.
• Add a read-only navigation command for opening a channel by id/name/url.
• Allow discord-app read to optionally target a channel instead of only the currently active channel.
• Add basic support for Forum/thread-style channels, where the channel view is a thread list rather than a normal message stream.

Use Case

As an OpenCLI user, I want to periodically read a few Discord channels that my logged-in Discord Desktop session can already access, so that I can build a local read-only digest/notification workflow.

Today this is possible for one active channel with:

opencli discord-app read --count 20 -f json

But reading multiple selected channels currently requires external UI automation to click each channel first. That is fragile because it depends on accessibility labels, visible sidebar state, scroll position, language, and Discord UI changes.

Forum channels are also different from normal text channels: the channel page shows a list of posts/threads, and read may return no normal messages until a specific thread is opened.

Proposed Solution

One possible CLI shape:

# List channels with stable metadata
opencli discord-app channels -f json
# => [{ "channel": "general", "type": "Text", "guild_id": "...", "channel_id": "...", "url": "https://discord.com/channels/.../..." }]

# Read-only channel navigation
opencli discord-app goto --guild <guild_id-or-name> --channel <channel_id-or-name>
opencli discord-app goto --url https://discord.com/channels/<guild_id>/<channel_id>

# Channel-targeted read that navigates internally, waits for the channel to load, then reads
opencli discord-app read --guild <guild_id-or-name> --channel <channel_id-or-name> --count 20 -f json
opencli discord-app read --url https://discord.com/channels/<guild_id>/<channel_id> --count 20 -f json

# Forum / thread support
opencli discord-app threads --channel <forum_channel_id> -f json
opencli discord-app thread-read --thread <thread_id> --count 20 -f json

Implementation ideas:

• Reuse Discord web routes (/channels/{guild_id}/{channel_id} and thread URLs) instead of relying on visual clicking when ids/URLs are available.
• After navigation, wait until the URL, channel header, or message list reflects the target channel before reading.
• Keep the adapter read-only: no message sending, deleting, reacting, or marking all as read.
• If opening a channel inherently changes Discord's unread state, document that behavior and keep the command explicit.
• For Forum channels, expose post/thread cards as structured records first, then allow opening and reading a selected thread.
• Preserve the current active-channel behavior as the default, so existing usage remains compatible.

Alternatives Considered

• External UI automation that clicks channels by visible labels. This works, but is brittle across sidebar scroll position, localization, accessibility tree changes, and Discord UI updates.
• Discord bot API. This is more stable where available, but many workspaces do not allow adding bots, while the Desktop session can already read the relevant channels.
• Manual channel switching before each read. This is fine for ad hoc use, but not reliable for low-frequency scheduled digests.

[ByteYue]

Small priority clarification after thinking through the implementation surface:

The most valuable first step would be ordinary text-channel support only:

1. discord-app channels -f json returns stable channel metadata (guild_id, channel_id, url, type).
2. discord-app goto --url ... or goto --guild ... --channel ... opens a normal text channel in read-only mode.
3. discord-app read --url ... --count N -f json (or equivalent --guild/--channel) internally navigates, waits for the target channel, then reuses the existing active-channel reader.

Forum/thread support can be treated as a later enhancement. It has a different surface area (thread list, right-side panel/thread routes, lazy-loaded cards/attachments), so it probably should not block the simpler text-channel navigation/read workflow.

In other words, a first version that only handles normal text channels would already remove the need for fragile external UI clicking for most scheduled read-only digest use cases.

[ByteYue]

Implemented a first pass in #1951.

What changed:

• discord-app channels / servers now expose stable ids and URLs.
• Added read-only discord-app goto for channel navigation by URL or ids.
• discord-app read can now target --url or --guild/--channel, while preserving the active-channel default.
• Added discord-app threads and discord-app thread-read for visible forum/thread-style channels.
• Added adapter tests and updated docs/manifest.

Validation notes:

• Ran syntax checks for the new/modified Discord adapter JS files with the bundled Node runtime.
• Ran manifest JSON parse and diff whitespace checks.
• Did a low-frequency read-only CDP smoke check against the locally running Discord debug port: target reachable, channel metadata extracted, and one recent message row shape verified without sending/clicking.
• Full Vitest was not run here because this checkout has no node_modules and the shell PATH has no npm/npx/bun.