[BUG] Plugin MCP failure cache is machine-wide and silent: one failing session disables a plugin for every session (incl. --channels daemons) for 15 min

Environment

• Claude Code 2.1.283 (native), macOS 15 arm64
• Plugin: telegram@claude-plugins-official (stdio MCP server started with bun), used via claude --channels plugin:telegram@claude-plugins-official

What happens

When a plugin's stdio MCP server fails to connect in any Claude Code session, the failure is recorded in ~/.claude/mcp-needs-auth-cache.json under the server name (plugin:telegram:telegram). For the next 15 minutes, every other session on the machine skips that server. /mcp shows Skipping connection (recent failure cached; retries automatically in 15 min, or edit the plugin config to retry now), but nothing is written to --debug-file, and the session otherwise boots normally.

For a --channels daemon this means the channel never starts, with no error anywhere. It looks like a random startup race.

Real-world impact

A launchd job in another project runs claude -p ... every ~10 minutes with a PATH that doesn't include bun. The telegram plugin fails there instantly (Connection failed after 3ms (ENOENT): Executable not found in $PATH: "bun"), which re-poisons the shared cache about every 21 minutes. My always-on --channels daemon, which has bun on its PATH and would connect fine, came up without the plugin about 70% of the time. Each restart needed 5 to 8 attempts until a boot landed in the ~6-minute gap between cache entries. It took reading debug logs from a failed and a successful boot side by side to find it.

Repro

1. Install any plugin with a stdio MCP server that needs a runtime on PATH (e.g. the official telegram plugin, which uses bun).
2. env PATH=/usr/bin:/bin claude -p "hi" (the plugin fails to connect).
3. Within 15 minutes, in a normal shell: claude --channels plugin:telegram@claude-plugins-official --debug-file /tmp/d.log
4. The plugin server never starts. /mcp shows the cached-failure message; /tmp/d.log has no line about skipping it.

Expected

A failure caused by one session's environment shouldn't silently disable the server for unrelated sessions, especially a server named in --channels.

Suggestions

• Scope the plugin failure entry to the session (or key it by something that includes the environment), or don't cache stdio startup failures across processes at all.
• Always write the skip to --debug-file.
• Never skip a server that the session explicitly requested via --channels.

Workaround

Delete the plugin:<name>:<server> entry from ~/.claude/mcp-needs-auth-cache.json before starting the daemon. My supervisor does this now: https://github.com/k1p1l0/claude-telegram-supercharged/blob/master/docs/DAEMON-TROUBLESHOOTING.md

Related: #80635 (the same name-keyed, machine-wide cache, poisoned by claude mcp list for HTTP servers).