[BUG] v2.1.208: `/mcp` settings menu blocked in actively-attended `claude agents` sessions — "background session" guard gates on launch path, not attachment
Environment
- Claude Code v2.1.208 (native install, auto-updated from v2.1.207)
- macOS (Darwin 25.5.0), zsh
- Session launched from the
claude agentsview (agent list → new session), user actively attached and typing into it
What happened
v2.1.208 shipped this change (from the changelog):
/install-github-appand the/mcpsettings menu no longer open in background sessions
The guard classifies every daemon-backed session as "background," including sessions the user is actively attached to in the agents view. Typing /mcp in a session I am sitting in and interacting with returns:
Can't open MCP settings in a background session — use /mcp enable|disable|reconnect <server> to steer, or run /mcp from an interactive terminal to authenticate.On v2.1.207 (as recently as the same evening, pre-auto-update) the same workflow opened the /mcp panel fine.
Steps to reproduce
- On v2.1.208, run
claude agentsin a terminal - Create/open a session from the agents view and attach to it
- Type
/mcp
Expected: the MCP settings panel opens — a user is attached and interacting, so this is functionally an interactive session (interactive OAuth flows have a browser available, etc.)
Actual: blocked with the "background session" error above.
Why this is a problem
- The
/mcpsubcommand forms (/mcp enable|disable|reconnect <server>) do still work, but the panel is the only way to authenticate OAuth-based servers (claude.ai connectors like Gmail/Calendar/Airtable) and the only way to browse server/tool status. Users who work primarily out of the agents view lose MCP auth entirely and must open a separate plainclaudesession just to re-auth. - The restriction gates on launch path (daemon-backed) rather than attachment state (is a human attached to this session right now). The stated rationale — don't open interactive settings UIs in unattended sessions — doesn't apply to an attended agents-view session.
- Because this landed via silent auto-update, it presents as sudden breakage mid-workflow with no indication that it was an intentional change.
Suggested fix
Gate the /mcp and /install-github-app panels on whether a user is currently attached to the session, not on whether the session is daemon-backed. Unattended/headless background jobs stay blocked; attended agents-view sessions regain the panel.
Related: #61053 (claude.ai MCP integrations not available in sessions launched from the agents view).
🤖 Filed with Claude Code on behalf of the user
6 Comments
Confirming this is still happening on v2.1.210 (macOS, Darwin 25.5.0), so it survived at least two releases past the v2.1.208 regression.
My repro
claude agents./mcp.``
/mcp
⎿ Can't open MCP settings in a background session — use /mcp enable|disable|reconnect <server> to steer, or run /mcp from an interactive terminal to authenticate.
/mcpworks fine, panel opens normally.So this isn't limited to sessions created from the agents view (as in the original report) — it also triggers on a session that was interactive-first and then sent to background, confirming the guard is keying off launch/daemon path rather than actual attachment state, exactly as the original report suspected. The fact that re-opening the identical session in a plain terminal fixes it is a pretty clean signal that the session itself is fine — it's purely the daemon-backed/background code path tripping the guard.
Still present in v2.1.211, and it also hits plain
claudelaunches — noclaude agentsinvolved — via pre-warmed spare sessions.Environment: Claude Code v2.1.211 (native, auto-updated 2026-07-16), macOS (Darwin 27.0.0), zsh.
Repro:
``
claude daemon run --origin transient ...
claude bg-spare --bg-spare /tmp/cc-daemon-501/.../spare/<id>.claim.sock
claude bg-pty-host --bg-pty-host ... 200 50 ...
claude(no flags, no agents view). The session claims a spare./mcp→Can't open MCP settings in a background session — ...The guard gates on the launch path (born as a background spare) rather than current attachment (real TTY, user typing), exactly as this issue describes — but through a path where the user never opted into anything background-related.
Additional data points:
/plugin→ Installed → MCP Server → Authenticate action is gated by the same guard:Can't authenticate MCP servers in a background session — run this from an interactive terminal.So both auth surfaces are closed.claude daemon stop --anykills the spares but they respawn shortly after, so that's not a workaround for regular terminal users.remoteControlAtStartup: falsedoesn't help (sessions still claim spares).claude mcp login <name>from a plain shell prompt does work and completes OAuth — but it requires a real TTY (stdin isn't a terminalotherwise), so there's no programmatic path, and end users have to discover and type fully-qualified server names likeplugin:cloudflare:cloudflare-apiby hand. That's a rough downgrade from the one-click panel flow in ≤v2.1.207.Suggested fix direction (echoing the OP): classify by current attachment (PTY present + user input) rather than by how the process was spawned — or at minimum allow the auth flow when a browser is reachable.
@bogini any update on this? this is becoming amazingly frustrating i cannot change models now either
Just sharing for others the obvious short term fix to return to the days of multi terminal tab switching before multi-agent view.
.claude/settings.json -> "disableAgentView": true
In normal single session agent view for me this returns the /mcp functionality
Hope to see a multi agent view fix soon!
Yes we have the same issue. Very annoying. Awaiting app-level fix.
Fixed in v2.1.214.
/mcp(and/install-github-app) is now only refused in background sessions with no terminal attached, rather than in every daemon-backed session, so it gates on attachment state instead of launch path. If the/plugin > Installed > Authenticateflow is still blocked on 2.1.214, or/mcpstill refuses with a terminal attached, reopen with your version and how the session was launched.