[BUG] VS Code integrated terminal: every request fails with 503 'pre-upstream queue is saturated'; native Terminal.app works (macOS)

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?

Running claude from the VS Code integrated terminal hangs ~15s on every request and then fails with a 503 service_unavailable ("pre-upstream queue is saturated"), retrying up to 11 times and never returning. Running the exact same binary from the native macOS Terminal.app returns a response in ~2–3 seconds, every time, with no retries.

The behavior is consistent, not intermittent: VS Code fails on every attempt, native succeeds on every attempt, including when run within the same time window.

Critically, debug logs show the request that gets sent is identical in both environments (source=sdk, same entrypoint, same model, same auth), and curl to the same endpoint succeeds instantly from both terminals. So this is neither a network issue nor a request-content difference — something about how the VS Code-spawned process establishes the API connection causes it to consistently land on a failing/saturated path.

What Should Happen?

claude -p "hi" from the VS Code integrated terminal should return a response in ~2–3s, the same as from native Terminal.app.

Error Messages/Logs

The outbound request is the same kind in both terminals; only the outcome differs.

**Native (`claude -p "hi"`, succeeds):**

[API REQUEST] /v1/messages x-client-request-id=dbce45c4-... source=sdk
... cc_entrypoint=sdk-cli; cch=00000;
Stream started - received first chunk
[API:timing] first byte after 2311ms


**VS Code (`claude -p "hi"`, fails):**

[API REQUEST] /v1/messages source=sdk
... cc_entrypoint=sdk-cli;
API error (attempt 1/11): 503 {"type":"error","error":{"type":"service_unavailable","message":"Anthropic pre-upstream queue is saturated. Please retry shortly."}}
API error (attempt 2/11): 503 ... (same)
... continues retrying ...


Same `source=sdk`, same `cc_entrypoint=sdk-cli`, same model, same OAuth auth. Native streams a first byte in 2.3s; VS Code waits ~15s per attempt and gets a 503 each time.

Steps to Reproduce

1. On macOS, open VS Code with the Claude Code extension installed/active.
2. Open the integrated terminal and run claude -p "hi".

• Observed: hangs ~15s, then API error (attempt 1/11): 503 service_unavailable, retries repeatedly, never returns.

1. Open native Terminal.app, cd to the same project, run claude -p "hi".

• Observed: returns a response in ~2–3s, no retries.

Note: the request that leaves the process is identical in both terminals (source=sdk, cc_entrypoint=sdk-cli, same model, same OAuth auth), and curl to the same endpoint succeeds instantly from both — so it is not network or request content.

Claude Model

Other

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.193 (cc_version=2.1.193.45e)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

VS Code integrated terminal

Additional Information

Environment

• Install method: npm-global, under nvm node v24.4.1 (/Users/<user>/.nvm/versions/node/v24.4.1/lib/node_modules/@anthropic-ai/claude-code)
• Editor: VS Code 1.126.0
• Plan / auth: Claude Max, OAuth (no API key; has Authorization header: false, OAuth token check passes)
• Model: claude-haiku-4-5-20251001
• Shells tested: native Terminal.app (zsh login shell) and VS Code integrated terminal (zsh)

Additional evidence

Network path is identical and healthy in BOTH terminals

Direct curl to the failing endpoint, run in each terminal:

time curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" \
  -X POST https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" -d '{}'

• Native: 401 0.228615s
• VS Code: 401 0.504596s

Both reach /v1/messages instantly (401 expected with empty/unauthed body). Rules out network, proxy, DNS, TLS/cert as the cause.

No proxy / Node TLS env differences

env | grep -i proxy returns nothing in both terminals. NODE_EXTRA_CA_CERTS, NODE_OPTIONS, NODE_TLS_REJECT_UNAUTHORIZED are all empty in both. (The mTLS: Creating HTTPS agent with custom certificates debug line appears in all runs including native — it is internal Claude Code behavior, not user cert config.)

Removing VS Code IDE integration does NOT fix it

• env -u CLAUDE_CODE_SSE_PORT claude -p "hi" → still hangs.
• env -u CLAUDE_CODE_SSE_PORT TERM_PROGRAM=xterm-256color claude -p "hi" → still hangs, with no IDE detection at all in the log (no ide MCP server, no SSE connection, no IDE lock-file logic) and still 503-loops.

Other things tested and ruled out

• MCP fully disabled — claude --strict-mcp-config --mcp-config '{"mcpServers":{}}' in the VS Code terminal. Still 503s. Rules out any MCP server (including the ide and claude-in-chrome servers).
• IDE lock files cleared — deleted ~/.claude/ide/*.lock (and the whole ~/.claude/ide/ directory), fully quit and reopened VS Code so a fresh lock/port is written. No change. Rules out the stale-lock-file mechanism described in #67897 / #42141.
• CLAUDE_CODE_SSE_PORT unset — still hangs.
• Plugins — failure occurs regardless; reduced to 3 plugins (context7, playwright, typescript-lsp) with no effect.

So the failure is not the IDE/SSE channel, not stale IDE lock files, not MCP, and not plugins.

Analysis / where it points

With network proven healthy in both terminals (curl) and the outbound request proven identical (debug logs), the difference cannot be in what is sent. It must be in how the VS Code-spawned Node process establishes/handles the HTTPS connection to the API — e.g. connection routing, socket/agent reuse, or runtime/networking inherited from the VS Code parent process — causing it to consistently hit a saturated server frontend while the native-shell process does not.

The 503 body (pre-upstream queue is saturated) is a server-side capacity signal, but the consistent per-terminal split (native always succeeds, VS Code always 503s) suggests it is not purely random load.

Workaround

Run Claude Code from native Terminal.app (works 100% of the time). VS Code can stay open as the editor alongside it. This loses the in-editor integration (diff tabs, IDE file context) but is fully functional.

What would help confirm

A same-second side-by-side capture (native + VS Code firing simultaneously) to definitively separate "server timing/load" from "VS Code-spawned process routes differently." The VS Code side hangs, so a strictly simultaneous capture was not possible.

Related issues

• #25253 — VSCode Plugin hangs after first request, terminal works fine (closest match)
• #41031 — Claude Code freezes in VS Code, only native Mac Terminal works (macOS)
• #30417 — VS Code extension hangs indefinitely, CLI works at all times (macOS)
• #67897, #42141 — stale CLAUDE_CODE_SSE_PORT hangs (ruled out here)