[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 agents view (agent list → new session), user actively attached and typing into it

What happened

v2.1.208 shipped this change (from the changelog):

/install-github-app and the /mcp settings 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

1. On v2.1.208, run claude agents in a terminal
2. Create/open a session from the agents view and attach to it
3. 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 /mcp subcommand 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 plain claude session 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