Background/bridge session launch silently writes project .mcp.json servers into disabledMcpjsonServers, persistently disabling them

Status Open

Maintainer reply None cached

Activity 0 comments · opened Aug 22, 2026

Summary

When a session is launched as a background job bridged from claude.ai/code (non-interactive bridge session), the harness writes the project's .mcp.json server names into both enabledMcpjsonServers and disabledMcpjsonServers in .claude/settings.local.json. Because disabled wins over enabled, and settings.local.json persists, this silently and permanently disables project MCP servers that the user had already approved — for all subsequent sessions, interactive ones included.

Environment

Claude Code on macOS (darwin 25.3.0)
Session launched as a background job bridged from claude.ai/code (bridge session)

Setup

The project has a .mcp.json with two OAuth HTTP MCP servers:

{
  "mcpServers": {
    "linear-fabulous-frequency": { "type": "http", "url": "https://mcp.linear.app/mcp" },
    "notion-fabulous-frequency": { "type": "http", "url": "https://mcp.notion.com/mcp" }
  }
}

Both were approved and worked in multiple interactive sessions over the prior week (verified in session transcripts).

Observed behavior

When a session was handed off to a background-job runtime (non-interactive), the harness created .claude/settings.local.json at the exact second of job startup (the job directory and the file were both created at 12:59:57 local) containing both lists populated:

{
  "enabledMcpjsonServers": ["notion-fabulous-frequency", "linear-fabulous-frequency"],
  "disabledMcpjsonServers": ["notion-fabulous-frequency", "linear-fabulous-frequency"]
}

Since the disabled list takes precedence over the enabled list, and settings.local.json persists across sessions, the servers were silently and permanently disabled from that point on.

No user action disabled them, and no agent tool call wrote the file — verified by grepping all session transcripts for writes to settings.local.json / disabledMcpjsonServers: zero hits. The write came from the harness itself at job startup.

Presumed cause

A non-interactive/background launch cannot run the OAuth/approval flow for HTTP MCP servers, and the harness records them as disabled — leaking a launch-context limitation into durable user configuration.

Expected behavior

A background session that cannot connect project MCP servers should skip them for that session only. It should not persist a disable that overrides prior user approval.

Impact

The user's project MCP setup (Linear/Notion workspace routing) silently broke. The globally-configured Linear server pointed at a different workspace, which risked writes to the wrong workspace.

Possibly related (not duplicates)

#75567 — approval for a project-scoped HTTP MCP server never persists (nothing is written); this issue is the inverse: a background launch writes a durable disable.
#88758 — Desktop app does not connect project-scoped .mcp.json HTTP MCP servers.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CdJwf46GeVjTjEoup8HTTV

View original on GitHub ↗