[BUG] SessionStart lists an authenticated, tool-loaded claude.ai connector under "requires authentication" and instructs the agent to announce it as unavailable

Summary

At session start (and re-injected in every subsequent <system-reminder> turn), Claude Code emits a block listing MCP servers that "require authentication." A claude.ai connector that is already authenticated — and whose action tools are loaded and callable in the very same session — is nonetheless listed there under an alias name, and the block ends with a standing imperative:

"Tell the user that these servers need to be authorized … and that the capability is unavailable until they do."

The result: the model reads the block, believes it, and tells the user the connector is unauthenticated/unavailable — even though the connector's tools are present and work on the first call. Because the instruction is re-injected each turn, this repeats across every agent/session on the affected connector.

This is distinct from (and in some sense the inverse of) #59434, where the connector's action tools are genuinely missing (only auth-handshake stubs are present). Here the action tools are surfaced and functional; only the reminder is wrong. #59434 is marked completed, but this residual variant is still live.

Environment

• Claude Code embedded in the Claude Desktop app, macOS
• Model: Claude Opus 4.8
• Connector: Linear (https://mcp.linear.app/mcp), status Connected in claude.ai → Settings → Connectors
• Session started non-interactively

Evidence / what actually happens

• The SessionStart reminder lists plugin:productivity:linear under "servers requiring authentication," followed by the imperative to tell the user it needs authorizing.
• Meanwhile the connector's real tools are registered in the same session under an opaque UUID server name (mcp__<uuid>__list_teams, …__list_issues, …__get_issue, …__create_issue, etc.). The alias flagged as "needs auth" and the actually-loaded working server are two names for the same connector.
• Calling one of those tools (list_teams) succeeds immediately and returns real workspace data — no auth prompt, no error.
• So the model is simultaneously (a) holding a working, authenticated tool and (b) being told, every turn, that the tool needs authentication and is unavailable. It follows the louder, repeated instruction and misreports the connector as down. When the user pushes back and the model finally calls the tool, it works — the classic "oops, you were right" reversal.

Steps to reproduce

1. Connect a claude.ai connector (e.g. Linear) so it shows Connected in claude.ai → Settings → Connectors.
2. Start a Claude Code session in the Desktop app.
3. Observe the SessionStart <system-reminder> lists the connector's plugin:<category>:<name> alias under "requires authentication," with the imperative to tell the user it must be authorized.
4. Ask the model whether the connector is available → it typically says no / not authenticated.
5. Force the issue; have it call one of the connector's tools → the call succeeds and returns data.

Expected

• The "requires authentication" block should not list connectors that are already authenticated and whose tools are loaded in the session.
• The two representations of one connector — the plugin:<category>:<name> alias and the actually-loaded UUID-named server — should be reconciled so the model never receives contradictory signals about the same connector.
• The block should not carry a standing, every-turn imperative to tell the user a connector is unavailable; at minimum it should be conditioned on the tools genuinely being absent, and phrased as a non-blocking notice.

Actual

Persistent, per-turn misinformation: the model tells the user an authenticated, working connector is unauthenticated/unavailable, until forced to test it.

Related

• #59434 (closed/completed) — authenticated connectors not surfaced in a running session; inverse symptom (tools missing there vs. tools present-but-flagged here), and the completion didn't cover this variant.
• #66290 (open) — the "needs auth" banner wedging message-injection in headless sessions; same false-needs-auth root, different symptom.
• #56889 (open, docs) — documenting the "needs auth" vs "failed" status distinction.
• #63036 (open, docs) — documenting the combined startup connector-auth notification.