// The guide

Claude Code background sessions and MCP auth: sign in once, run everywhere.

2026-07-16 · 5 min read · by Nabil BA-MOH

You launch a background Claude Code session, it needs a cloud connector, and /mcp refuses to open: "run /mcp from an interactive terminal to authenticate". That message is not a bug, and the workaround is simpler than it looks. Authenticate once in an interactive session and every session on the machine — foreground or background — reuses the same credentials.

Everything below is from running long-lived background sessions daily, verified in July 2026.

Why /mcp refuses in background sessions

Since Claude Code v2.1.200, the interactive /mcp settings menu will not open inside a background session. The reason is mechanical: MCP OAuth flows open a browser and wait for the redirect, and a background session has no TTY to drive that from. Rather than hang or half-work, Claude Code now tells you to do it from an interactive terminal.

So the restriction is real, but it restricts the menu, not the credentials.

The model: one credential store, every session reads it

Here is the part that is easy to miss. MCP and connector credentials live in a shared store on the machine, not inside a session. That gives you a simple contract:

• Authenticate once, interactively. Open a normal Claude Code session, run the OAuth flow, done.
• Every other session reuses it. Background sessions read the same store. They never need their own sign-in.
• Refresh is automatic. Expired access tokens are refreshed without you doing anything. A past release fixed the one rough edge here — OAuth MCP servers no longer require manual re-authentication after a failed token refresh.
• Headless setups have a CLI path. claude mcp login <name> and claude mcp logout <name> exist for scripted or remote environments where you want auth handled outside any session.

Our own proof: after a single interactive sign-in, cloud connectors — Gmail and Google Calendar — kept answering from a background session repeatedly across hours. Zero re-auth prompts, zero babysitting.

The wake-from-sleep bug that made this look broken

If you ran parallel sessions earlier in 2026 and saw all of them log out at once after your laptop woke from sleep, that was real: a race on the shared credential store. It was fixed in v2.1.211. If you are on an older build and see mass logouts after wake, update before you blame your setup.

Practical rules for long-running agents

Three rules cover almost every failure you will actually see:

1. A 401 on the Anthropic OAuth kills every session; one /login revives every session. If a long-running background agent dies with a 401, open any interactive session, run /login, and the background agents pick the fresh credentials up. You do not need to restart them one by one with their own auth.
2. Never use claude -p to check connector state. A headless one-shot probe does not mount cloud connectors at all. It will tell you the connector is missing when it is fine. It is the wrong instrument, not a diagnosis.
3. Daemon background jobs do mount connectors. Long-lived background sessions get the full connector surface. The distinction is the session type, not "background vs foreground".

The pattern, in one line

Interactive sessions are where auth is born; background sessions are where it gets used. Design your setup around that split and MCP auth stops being a topic.

Running long sessions? You will also want the auto-compact threshold that actually exists.

FAQ