[BUG] claude.ai MCP integrations (Gmail, Google Calendar) not available in -p mode or --resume sessions since v2.1.79

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/26364
2. https://github.com/anthropics/claude-code/issues/27647
3. https://github.com/anthropics/claude-code/issues/29345

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Not a duplicate, the referenced issues are older, and the previous version (2.1.78) which is from after those issues, had this working. The problem started with 2.1.79 -> i downgraded to 2.1.78 and confirmed it works

+1 for this, it's a regression

frustrating regression :+1:

I am also seeing this

Confirming I also see this regression. The workflow I describe below worked prior to 2.1.79; I'm on 2.1.81 now.

My logs show claude -p actually connects to the MCP servers. But there's a race condition or timing issue: the prompt executes _before_ MCP servers can connect successfully.

I had Opus analyze debug logs for a claude -p prompt which interacts with Linear, and it reports this:

  Timeline from the debug log:

  14:32:35.077  Neon connected        (211ms)
  14:32:35.220  claude.ai servers START connecting
  14:32:35.373  *** API REQUEST SENT ***   ← only Neon's tools included
  14:32:35.696  Gmail connected       (476ms)  — too late
  14:32:35.815  Calendar connected    (594ms)  — too late
  14:32:36.241  Figma connected       (1020ms) — too late
  14:32:37.897  Linear connected      (2675ms) — too late
  14:32:38.466  First API response chunk arrives

Could be a server latency issue on the Anthropic or Linear end, or could be non-determinism in Opus's response to a failed tool call (API call isn't retried if a connection fails?), or something else altogether.

But the server connections _seem_ to be there, they're just too late for purposes of claude -p.

Right, this is a blocker!
https://github.com/anthropics/claude-code/issues/37121

Root Cause Confirmed (v2.1.81 binary reverse-engineering)

I spent a day tracing this through the compiled binary. Here is the exact code path:

The Two-Phase MCP Initialization

// Phase 1: Fetch cloud MCP server list — runs in BOTH modes ✓
cloudServers = isPrintMode && !isSimpleMode && !hasEnterpriseMcp()
  ? fetchCloudMcpServers()   // <-- this DOES run in -p mode
  : Promise.resolve({});

// Phase 2: Connect to individual MCP servers — HARDCODED SKIP in -p mode ✗
cloudMcp = isPrintMode
  ? Promise.resolve({ clients: [], tools: [], commands: [] })  // always empty!
  : cloudServers.then(connectServers);

// Merge local + cloud
allMcp = Promise.all([localMcp, cloudMcp]).then(merge);

The isPrintMode ternary on Phase 2 unconditionally skips cloud MCP connection. The server list is fetched (visible in DEBUG=* logs as a request to /v1/mcp_servers?limit=1000), but the individual server connections are never established.

Verification

• Confirmed keychain/OAuth tokens are accessible ✓
• Confirmed API endpoints are reachable (0.6s latency) ✓
• Confirmed security find-generic-password works from LaunchAgent context ✓
• Confirmed same behavior from Terminal and from macOS LaunchAgent ✓
• claude -p from terminal also shows 0 cloud MCP tools — it's not a daemon/keychain issue

@guibonaccorsi's regression note

If this worked in v2.1.78, the isPrintMode gate on Phase 2 was likely added in v2.1.79. Possibly intentional (startup speed optimization?) but it breaks all non-interactive use cases.

Workaround

Configure cloud MCP servers as local stdio servers in .mcp.json using mcp-remote:

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.context7.com/mcp"]
    }
  }
}

This works for servers without OAuth (Context7). For OAuth-protected servers (Jira, Slack, Notion, Gmail, Calendar), mcp-remote requires individual OAuth flows per server.

Suggested Fix

Remove the -p gate on Phase 2, or add an opt-in flag:

// Option A: Always connect (recommended)
cloudMcp = cloudServers.then(connectIfAny);

// Option B: Opt-in flag
cloudMcp = (isPrintMode && !enableCloudMcpFlag)
  ? Promise.resolve({})
  : cloudServers.then(connectIfAny);

Same issue with claude.ai Slack MCP.

Debug logs confirm the server connects successfully but tools are not registered as deferred tools:

MCP server "claude.ai Slack": Successfully connected to claudeai-proxy server in 1238ms
MCP server "claude.ai Slack": Connection established with capabilities: {"hasTools":true,...}

ToolSearchTool: keyword search for "slack", found 0 matches
Dynamic tool loading: 0/44 deferred tools included

44 deferred tools exist (non-MCP ones), but none of the claude.ai MCP tools are among them.

Repro:

claude -p --model haiku --allowedTools 'mcp__claude_ai_Slack__slack_send_message' \
  "Send 'hello' to Slack channel C0612345"

Claude Code version: latest (as of 2026-03-25)
Platform: macOS (Apple Silicon)

This is a big problem 😱

Confirmed on our end as well. We run an automated meeting-minutes pipeline (claude -p --output-format stream-json) that relies on the claude_ai_bear (Bear Notes) MCP server for reading and writing notes.

• v2.1.78: cloud MCP tools load and work correctly in -p mode
• v2.1.79 / v2.1.80: cloud MCP tools silently absent — claude -p reports zero mcp__claude_ai_bear__* tools
• Workaround: pinned to v2.1.78 (npm install -g @anthropic-ai/claude-code@2.1.78)

This is a blocker for any non-interactive automation that depends on claude.ai MCP connectors. We process ~8 meetings/day through this pipeline and cannot upgrade past 2.1.78.

Separately, even on 2.1.78 we hit a related but distinct issue where the MCP proxy (mcp-proxy.anthropic.com) silently drops individual tool results — filed as #38437.

This appears to be resolved in v2.1.84. Cloud MCP servers (Gmail, Calendar, Slack, Atlassian, Figma, Supabase) all load correctly in -p mode now.

I run a headless morning briefing via launchd that creates a Gmail draft using claude -p — it's been broken since 2.1.79 and started working again today on 2.1.84.

Tested with: claude -p "List MCP tools starting with mcp__claude_ai" --allowedTools "mcp__claude_ai_Gmail__gmail_search_messages"

All cloud MCP tools returned consistently across multiple runs.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.