--resume + --dangerously-load-development-channels: silent bot (notifications routed to dead session ID)

Resolved 💬 3 comments Opened May 10, 2026 by duquesnay Closed May 13, 2026

Summary

Combining --resume <session> with --dangerously-load-development-channels plugin:X@Y causes the session to:

  1. Load the channel twice (duplicated in TUI banner)
  2. Route inbound MCP notifications to the OLD session ID from --resume rather than the new live session

Result: bot appears silent — no ← <channel> · ... lines in TUI, no reply tool calls, no error.

Reproduction (claude-code v2.1.138, macOS Darwin 23.6)

  1. Build a channel-MCP plugin (custom, via local marketplace claude plugin install ...).
  2. First run: claude --dangerously-load-development-channels plugin:myplugin@mymarketplace --name foo. Confirm dev-channels prompt.
  3. Drive some inbound to verify it works (e.g. Slack DM if it's a Slack-bridge plugin).
  4. Exit cleanly (/exit).
  5. Restart with --resume: claude --resume foo --dangerously-load-development-channels plugin:myplugin@mymarketplace --name foo
  6. Confirm the dev-channels prompt again.

Symptom

TUI banner shows the channel twice:

Listening for channel messages from: plugin:myplugin@mymarketplace, plugin:myplugin@mymarketplace

MCP debug log (~/Library/Caches/claude-cli-nodejs/<proj>/mcp-logs-plugin-<plugin>-<server>/<ts>.jsonl) shows session ID mismatch:

{"debug":"Connection established with capabilities: ...", "sessionId":"NEW_UUID"}
{"debug":"Channel notifications registered", "sessionId":"OLD_UUID"}   ← from --resume

When the MCP server emits notifications/claude/channel, claude code routes by the registered session ID (OLD_UUID) which is no longer the active session — notifications are dropped silently.

User-visible: bot processes the inbound side-effects that happen in the MCP server (reactions, status updates, etc.) but the claude session never sees the inbound text and never calls reply tools.

Expected

Either:

  • (a) deduplicate the channel registration on --resume + --dangerously so notifications route to the live session
  • (b) reject the combo at startup with a clear error

Actual

Silent bot. No error in MCP log, no error in claude stderr. Only the duplicated TUI banner hints at the issue, and only if you know what to look for.

Workaround

Drop --resume. Start fresh sessions every time. Loses transcript continuity inter-restart but the bot works.

Environment

  • claude-code: 2.1.138
  • OS: macOS 15.6 (Darwin 23.6)
  • Model: Opus 4.7 with xhigh effort
  • Plugin: custom (Slack channel via Socket Mode, local marketplace install)

Diagnosis context

Spent ~3h debugging this assuming it was a Slack-side issue (token, scope, app reinstall) before the duplicated TUI banner pointed to the real cause. Documented at https://github.com/duquesnay/claude-channel-slack-zeta/blob/main/CLAUDE.md (Gotcha #5) and decision-journal.md.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗