[BUG] Cowork: custom MCP connector reports "needs authorization / no tools" on every session spawn, despite valid working auth — server-side logs included

Update: new evidence narrows the mechanism to a race between session tool-discovery and an async credential-attach/refresh — and escalates severity for scheduled tasks.

The failure is upstream of tool calls: the tools never enter the session

In failing sessions, the connector's tools are entirely absent from the session's tool registry. The session's tool lookup reports No matching deferred tools found, and the model correctly concludes it can do nothing — there is no tool to call, so no model-level retry/mitigation is possible (we tried a skill-level "retry before surfacing auth" instruction; it can never execute because there is nothing to invoke).

The recovery path exists — it just loses the race most of the time

Three consecutive Cowork app launches, ~40s apart, same authorised connector (server-side timestamps, UTC 2026-07-13):

09:50:50  401 /mcp → discovery → /register 201 → nothing more     ← run 1: session reports "needs authorization"
09:51:22  401 /mcp → discovery → /register 201
09:51:35     └→ POST /token 200  (refresh_token grant — no /authorize, no IdP roundtrip)
09:51:36+       POST /mcp 200, 200 …                              ← run 2: tools present, query succeeds
09:52:08  401 /mcp → discovery → /register 201 → nothing more     ← run 3: "needs authorization" again

All three spawns begin identically: a credential-less probe, correct 401 + WWW-Authenticate, then a fresh (orphan) DCR registration. In the one successful run, a silent refresh-token exchange followed ~13 seconds after the probe, credentials attached, and the tools appeared. In the failing runs that follow-up never fired. So the client-side recovery mechanism exists and works — whether a session gets tools appears to be a race between async credential attachment and the session's tool-discovery step. This is also consistent with "ask again on a later turn usually works": by the next turn the refresh has completed.

Severity: scheduled tasks make this unattended

Cowork's scheduled tasks run locally (the app must be open), i.e. through this same session bootstrap. A scheduled run that loses the race has no second turn and no human to retry — in our 3-launch sample above, 2 of 3 spawns lost it. This effectively makes OAuth custom connectors unusable for scheduled/automated tasks until this is fixed.

Suggested-fix refinement

Given the above, the minimal fix looks precisely like the original report's #1/#2: block (or re-run) tool discovery on completion of credential attachment — the refresh that already happens at ~13s just needs to gate/refresh the session's tool registry instead of racing it. Fix #4 (reuse the existing DCR registration rather than re-registering per spawn) remains important: every launch currently orphans a registration server-side.

Happy to supply correlated server logs for any reproduction window.

Final characterisation: connector credential-attach is late (25–100s) in ~half of session spawns and absent entirely in the rest. Client-side mitigation is exhausted.

We instrumented both sides further: the server now serves the discovery handshake anonymously (so every session registers the tools and failures become observable tools/call 401s instead of an empty tool registry), and a skill-level retry ladder makes the model retry auth failures. Result across six instrumented Cowork session spawns (2026-07-13, UTC):

| Session spawn | Credentials attached |
|---|---|
| 11:05 | ~25s after spawn → recovered, tool calls succeeded |
| 11:06 | never |
| 11:07 | never |
| 11:17 | ~100s → recovered on a later user turn |
| 11:30 | ~31s — 4 seconds after the model exhausted its retries |
| 11:34 | never (observed ≥68s) |

Additional observations that should help localise the defect:

• No token exchange is involved in a successful attach. The 11:30 recovery served tool calls with an access token minted 24 minutes earlier in a different session (no /authorize, no /token in the window) — the backend already holds valid credentials and simply connects them to the session late, or never.
• Split credential state within one session: the SSE GET /mcp connected with a valid token while tools/call POSTs from the same session presented none/dead ones (11:17 session).
• The client's error wording is unreliable: "token has expired — requires re-authorization" was reported for a session whose backend demonstrably held a still-valid token (it served the 200s minutes later, unrefreshed).

With tool registration guaranteed server-side and model-level retries in place, the remaining failure rate is entirely the never-attach population — unreachable by any server or prompt mitigation. The fix needs to be in the session bootstrap: attach stored connector credentials before (or gate tool availability on) the session's first tool use, and treat a 401 as "re-check backend credentials", not "prompt the user".

Happy to share correlated server logs for any window, or test candidate builds.

Update 3: header-presence instrumentation + a decisive experiment. The failing client never sends credentials at all; the defect localizes to plugin-declared MCP servers in Cowork's sandbox; connector-only setup eliminates the user-facing failure.

We added two things to the server since the last comment: every /mcp 401 now logs whether an Authorization header was present, and every failed token verification logs the failing claim. That closes the gap in our earlier comments, which could not distinguish "no token" from "dead token". Findings from today's instrumented sessions (2026-07-13, UTC):

1. Failing calls carry no Authorization header — ever.
Every failing tools/call in every session logged hasAuthHeader: false. Not one expired or invalid token was presented in any failure window (token_verification_failed never fired). The client-side error wording ("token has expired — requires re-authorization") describes a token that was never sent.

2. There are two distinct MCP clients per session, and only one of them ever authenticates.

• claude-code/2.1.205 (local-agent, agent-sdk/0.3.205), connecting from the user's machine: sends initialize/tools/list/tools/call with no Authorization header, in every request of every session, including retries 45+ seconds in and after a mid-session reconnect handshake.
• Claude-User (Anthropic infrastructure): presents a valid JWT from the stored grant and has never failed — including serving the same query seconds after the local-agent's 401s.

This reframes our earlier "credentials attach late (25–100s) or never" table: server-side, credentials never attach to the local-agent client at all. What we measured as "attach" is the call being served by the other client. It is a routing/architecture defect, not attach latency.

3. Decisive experiment: the local-agent client comes from the plugin's .mcp.json.
We removed the MCP server declaration from the plugin (keeping the same server authorized as a claude.ai custom connector) and re-ran the repro. Result: the first query of a fresh Cowork session succeeded first-time via Claude-User — zero tools/call 401s, no auth prompt. Sequence for the full session:

15:02:31  local-agent: initialize 200, tools/list 200 (served anonymously), GET /mcp 401,
          discovery fetches, POST /register 201        ← sandbox still probes, credential-less
15:03:10  Claude-User: tools/call 200 (valid JWT)       ← user's query, first attempt
15:03:31  Claude-User: tools/call 200

So: a plugin-declared remote MCP server with OAuth is structurally broken in Cowork — the sandbox client it spawns has no credential path, while the working backend client sits beside it. Connector-only configuration is a full workaround for the user-facing failure.

4. Still broken even in connector-only mode: the credential-less probe and the orphan DCR registrations.
The sandbox client still probes on every session spawn and performs a fresh DCR registration each time (observed: 6 orphan POST /register 201 in one afternoon, including two within a single session). Servers that persist registrations per the SDK contract accrue these without bound.

Refined suggested fixes:

1. Route sandbox MCP traffic for OAuth connectors through the backend client that holds the grant (it already exists and works), or provision session-scoped credentials to the sandbox client — either resolves the plugin-declared case too.
2. Don't DCR-register on every spawn; reuse the existing registration.
3. Fix the error wording: a request that sent no token should not report "token has expired".

Happy to provide correlated logs for any window or test candidate builds.