[BUG] --channels (Discord bridge) silently stops processing inbound messages after background auto-update; persists on latest version

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

The --channels background bridge (claude --channels plugin:discord@claude-plugins-official, run as a long-lived launchd service wrapping a screen session) stops delivering inbound messages to the model. It silently stops auto-replying to new Discord messages — no crash, no error, the process stays alive and healthy indefinitely.

This started partway through 2026-10-07 after working normally for weeks. It has persisted across 3 silent background auto-updates since then (2.1.293 → 2.1.294 → 2.1.295) and survives a full OS reboot plus a fresh relaunch of the service.

What Should Happen?

A new inbound Discord DM should cause the --channels host to spawn/continue a session and call the plugin's reply tool, exactly as it did reliably before 2026-10-07.

Error Messages/Logs

No errors anywhere. The launchd job's StandardOutPath/StandardErrorPath log files for the service are empty (0 bytes) throughout. `screen -X hardcopy` of the session's terminal buffer is also empty. The only way to see any log output at all was running the plugin's own server.ts standalone outside the claude host (see repro steps) — that does log normally to stderr.

Steps to Reproduce

1. Set up the official Discord channel plugin (plugin:discord@claude-plugins-official) long-lived: claude --channels plugin:discord@claude-plugins-official (here via a screen session managed by a launchd LaunchAgent with KeepAlive — but the host CLI itself is what stops working, not the service wrapper).
2. It worked normally for weeks: inbound Discord DMs were received and auto-replied to correctly.
3. Sometime during 2026-10-07 (JST) it stopped replying to any new inbound message. No config or code changed on our side.
4. Diagnosed step by step, ruling out everything except the CLI host:

• Bot token / access list: confirmed fine — manually calling the plugin's fetch_messages and reply MCP tools from a separate, unrelated Claude Code session works perfectly (reads history, sends messages successfully).
• Discord Gateway connectivity: confirmed fine — ran the plugin's own server.ts standalone with bun run server.ts (the exact code the host spawns as its MCP server) and watched it connect successfully (discord channel: gateway connected as <bot>#...), receive a live test DM, and correctly emit the expected notification over stdout:

{"method":"notifications/claude/channel","params":{"content":"テスト","meta":{"chat_id":"...","message_id":"...","user":"...","user_id":"...","ts":"..."}},"jsonrpc":"2.0"}

• So the plugin/MCP server works correctly end-to-end, up through emitting the notification.
• The claude --channels ... host process — which should consume that notification, spawn/continue a session, and call reply — does nothing with it. No reply appears on Discord, no log output anywhere, the process just sits idle.

1. Restarted the background service (launchctl kickstart -k ...) and separately did a full OS reboot — issue persists both times.
2. Confirmed this is not fixed by auto-update: ~/.local/share/claude/versions/ shows 3 different versions silently installed within ~36 hours (2.1.293 at 2026-10-08 05:33, 2.1.294 at 2026-10-08 14:26, 2.1.295 at 2026-10-09 06:00). Reproduced again on 2.1.295 (the newest), confirmed right after a reboot with the service freshly relaunched on that exact version.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown exact build (not retained on disk) — last confirmed working the morning of 2026-10-07 JST, broke later that same day. Likely the version installed immediately prior to 2.1.293.

Claude Code Version

2.1.295 (Claude Code) — also reproduced on 2.1.293 and 2.1.294

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Non-interactive/CI environment

Additional Information

Environment: macOS (Darwin 25.6.0), Apple Silicon. The bridge runs as a launchd LaunchAgent wrapping screen -S discord-channel claude --channels plugin:discord@claude-plugins-official.

Note: other, separate Claude Code sessions on the same machine (e.g. other open desktop-app tabs) each spawn their own independent instance of the Discord plugin's MCP server whenever the plugin is enabled, each opening its own Gateway connection with the same bot token. Unsure if concurrent connections are related — flagging in case it's relevant.

This was diagnosed and written up by Claude Code itself during a live troubleshooting session with the end user (who is non-technical). Happy to provide the full diagnostic transcript or run further tests if useful.