[BUG] claude.ai connector: transient 403 (mcp_request_blocked) is cached as needs-auth; later sessions skip the connector and re-authorizing can't clear it

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

When the upstream server behind a claude.ai connector returns a transient 403 through the claude.ai MCP proxy during initialize or tools/list, Claude Code flags the connector as needing authentication and writes an entry to ~/.claude/mcp-needs-auth-cache.json.

That one failed request then takes the connector away from every session that starts later:

• Later sessions skip the connector entirely. They make no connection attempt and get no tools, and the session-start notice tells the model to ask the user to re-authorize it on claude.ai.
• Re-authorizing on claude.ai doesn't help. I disconnected and reconnected the connector several times, and the local entry stayed. The connector kept working on claude.ai while staying unavailable in Claude Code.
• Only deleting the entry from the cache file brings it back. #101509 reports that toggling the server in /mcp also works.

The 403 isn't an auth failure. The proxy returns permission_error with error_code: mcp_request_blocked ("The request may have been blocked by a firewall or security service"), and it's intermittent:

• In 8 fresh claude -p sessions started back to back, 3 got the 403 and 5 connected and listed tools normally. The account, credentials, and machine were the same, and the sessions were seconds apart.
• In 4 of the 10 failures it happened on tools/list, after initialize had already succeeded on the same connection.

The flag is also applied inconsistently. When the same 403 hit a tools/call in the middle of a session, Claude Code reconnected, the next calls succeeded, and nothing was flagged. Only failures in the startup path persist.

Two related effects:

1. A running session never retries. A process that started while the entry was cached stays without the connector for its whole lifetime, even after the entry is removed. This is painful in long-lived SDK sessions, where one IDE or desktop thread is a single process for hours.
2. The stale notice comes back after compaction. After auto-compaction, the needs-auth notice captured at session start was re-inserted word for word, even though the cache file had no claude.ai entries at that point.

What Should Happen?

• Only treat a claude.ai proxy error as needs-auth when it is actually an auth failure: a 401, or a 403 whose error type or code is auth-related. Treat mcp_request_blocked as a connection failure: retry with backoff, report "failed to connect", and don't write it to the needs-auth cache.
• Clear (or at least re-check) a claude.ai connector's needs-auth entry when claude.ai reports the connector as connected, so that re-authorizing on claude.ai fixes it. Ideally, claude.ai connectors would be retried at every session start instead of skipped.
• Let a running session retry a connector that it skipped at startup. Also, the notice re-inserted after compaction should reflect the current status, not the startup snapshot.

Error Messages/Logs

# ~/.cache/claude-cli-nodejs/<cwd>/mcp-logs-claude-ai-Wispr-Flow/<session>.jsonl
17:08:28.176 Connection error: Error POSTing to endpoint: {"type":"error","error":{"type":"permission_error","message":"MCP server returned 403 Forbidden. The request may have been blocked by a firewall or security service.","details":{"error_code":"mcp_request_blocked"}},"request_id":"req_011Cfzc1rsJ1HZsKvXv1XvCp"}
17:08:28.177 tools/list 401/403 on claude.ai proxy — flagging needs-auth

# ~/.claude/mcp-needs-auth-cache.json afterwards
{"claude.ai Wispr Flow": {"timestamp": 1791911308177}, ...}

# Every later session: system/init shows the connector as needs-auth,
# no new connection is logged for it, and none of its tools are listed.

Every mcp_request_blocked error in my local MCP logs, which go back to July, with proxy request IDs (UTC). All 10 are from one connector, Wispr Flow:

| Time (UTC) | Request | Request ID | Flagged? |
|---|---|---|---|
| 2026-10-06 14:20:33 | tools/list | req_011Cfm8YnVvBC9Vck9NSoHZv | yes |
| 2026-10-12 17:09:14 | initialize | req_011CfxiGNAW1wdYPFf7ZC75p | yes |
| 2026-10-13 12:01:27 | initialize | req_011CfzCbz4HjU8eUTEfCT6Dn | yes |
| 2026-10-13 15:20:12 | initialize | req_011CfzTm2Ekd76A3gERucd1D | yes |
| 2026-10-13 16:14:25 | tools/list | req_011CfzXtp5x5VPzaVA4JxrTe | yes |
| 2026-10-13 16:26:58 | initialize | req_011CfzYrKy5PYSbqcWE8cxp8 | yes |
| 2026-10-13 16:37:44 | tools/call | req_011CfzZfvcyY76aWqX2QNkn2 | no (recovered) |
| 2026-10-13 17:06:23 | initialize | req_011CfzbrhMJWCv5JThz5hMuz | yes |
| 2026-10-13 17:07:00 | tools/list | req_011CfzbuQBWuXJo12PLpCXpp | yes |
| 2026-10-13 17:08:28 | tools/list | req_011Cfzc1rsJ1HZsKvXv1XvCp | yes |

Steps to Reproduce

1. Connect a claude.ai connector whose server sometimes returns 403 to the proxy. Wispr Flow did this for me, about 1 in 3 connections on Oct 13. Sign in to Claude Code with the same claude.ai account.
2. Start fresh sessions repeatedly: claude -p "hi" --output-format stream-json --verbose. Check the connector's status in mcp_servers in the system/init event.
3. When a session hits the 403, its MCP log shows flagging needs-auth, and ~/.claude/mcp-needs-auth-cache.json gains a "claude.ai <Connector>" entry.
4. Every later session shows the connector as needs-auth without trying to connect, and none of its tools are available.
5. Disconnect and reconnect the connector on claude.ai. Step 4 still happens.
6. Delete that key from ~/.claude/mcp-needs-auth-cache.json. The next session connects normally.

Workaround I'm using: a SessionStart + Stop hook that removes claude.ai -prefixed keys from the cache file. It works for the next session or turn, but not for the session that was already blocked, because the cache is read before SessionStart hooks run.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.296 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

• Reproduced in plain claude -p from a terminal and in long-lived SDK sessions (--input-format stream-json) run by a desktop app. The model doesn't matter, and neither does the connector's tool-permission setting: the failures happen before any tool call, and they continued after I set every tool to "Always allow".
• No other claude.ai connector on the same account has hit this. The vendor is the likely source of the 403s themselves, and I've reported those to them separately. This issue is about how Claude Code handles them.
• Related: #101509 (the same stuck "Needs Auth" that re-authorizing can't clear, in VS Code), #89604 (a false needs-auth notice for claude.ai connectors in headless sessions), and #80635 / #80822 (the needs-auth cache blocking servers in later runs).