[BUG] Discord channels: intermittent "not allowlisted" on reply — still reproduces on v2.1.220 (macOS)

Preflight Checklist

• [x] I have searched existing issues
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

Running claude --channels plugin:discord@claude-plugins-official, the reply tool intermittently fails with:

reply failed: channel <id> is not allowlisted — add via /discord:access

access.json is correct and untouched (dmPolicy: allowlist, my user ID in allowFrom). The same session replies successfully before and after the failure, with no configuration change in between.

This is the same symptom as #47680, which was closed as a duplicate of #36837 (a different, Linux-only "gateway never delivers messages" bug). #36837 was then auto-closed as stale and locked. #41647 (null recipientId) was also closed as duplicate, and its suggested fix — the dmChannelUsers fallback — is already present in plugin 0.0.4 (server.ts ~line 830), so that is not the cause here.

So there is currently no open issue tracking this symptom, and it still reproduces on the latest version.

Why this matters

When reply fails, nothing reaches the user at all — there is no fallback delivery path. From the user's phone, a failed reply is indistinguishable from Claude simply not responding. The only outbound channel is the one that breaks.

Environment

• Claude Code: 2.1.220 (the failure below was recorded on this version)
• Plugin: plugin:discord@claude-plugins-official 0.0.4
• macOS 25.5.0, Apple Silicon (M1)
• Plain interactive session in Terminal.app (not tmux, not --bg)

Evidence

Log source: ~/Library/Caches/claude-cli-nodejs/*/mcp-logs-plugin-discord-discord/*.jsonl

A single session, succeeding → failing → succeeding, with no config change (all times UTC):

02:08:24  Channel notifications registered   (session start, v2.1.220)
02:12:17  Tool 'reply' completed successfully
02:15:33  reply failed: channel ... is not allowlisted
02:16:42  Tool 'reply' completed successfully

This rules out a cold-cache / startup-only explanation: the same process had already replied successfully 3 minutes earlier.

Aggregate over all sessions (17 failures, 2026-07-23 → 2026-07-25):

| | |
|---|---|
| Total not allowlisted failures | 17 |
| Recovered within 5s | 0 |
| Time to next successful reply in the same session | min 29s / median 375s (~6 min) / max 777s (~13 min) |
| Never recovered within that session | 5 |

Note: those durations are upper bounds — they depend on when the assistant next attempted a reply, not on when the block actually lifted. But a retry 12 seconds after a failure also failed (23:26:26 fail → 23:26:38 fail → 23:27:21 success), so the block lasts longer than a few seconds.

Partial disagreement with #47680's analysis

#47680 states the block is lifted only when an inbound MCP notification arrives. Checking each failure against the log for inbound notifications/claude/channel* events between the failure and the next success:

recovered with an inbound in between : 9
recovered with NO inbound in between : 3   <-- contradicts "only"
undetermined (no later success in that session) : 5

The three no-inbound recoveries: 2026-07-24T23:26:38 (+43s), 2026-07-24T23:30:05 (+29s), 2026-07-24T12:45:06 (+360s).

Caveat: "no inbound" means no logged notifications/claude/channel* line; if inbound events exist that are not written to this log, they would not be visible here.

So the transport-stall hypothesis may be right, but it also appears to time out on its own, which might narrow down where the stall is.

Steps to reproduce

Not reliably reproducible on demand. It occurs during ordinary DM exchanges, several times per day. One deliberate reproduction that worked: start a second session with --channels while another is already running; the newly started session's first reply failed with this error while the older session replied successfully to the same inbound message.

Expected behavior

reply should succeed whenever access.json allows the sender, regardless of how long the session has been processing.

Workaround in use

Retry the reply after ~1 minute, up to 3 times. Sending any DM from the user side also clears it (consistent with #47680).