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

Nice isolation work — you've already ruled out the two usual culprits (request content and raw network), since the debug request is byte-identical and curl succeeds from both terminals. That leaves exactly one variable: the environment the process inherits from its parent. VS Code's integrated terminal injects a different env than Terminal.app, and 503 "pre-upstream queue is saturated" is a server-side gateway/queue response — so something the VS Code-spawned process carries is routing its connection onto a throttled/saturated upstream path, even though the request body is the same. Because curl works from the same VS Code terminal but the CLI doesn't, the difference is almost certainly in the transport layer (proxy / TLS / HTTP version / connection reuse), which Node's HTTP client (undici) and curl handle with different env semantics — not in anything you typed.

Fastest way to pin it down:

1. Diff the two environments. From the VS Code integrated terminal:

env | sort > /tmp/vscode-env.txt

From Terminal.app:

env | sort > /tmp/native-env.txt

then

diff /tmp/native-env.txt /tmp/vscode-env.txt

The lines that only exist on the VS Code side are your suspect list.

2. Re-run with the likely suspects stripped. In the VS Code terminal:

env -u HTTPS_PROXY -u HTTP_PROXY -u ALL_PROXY -u NO_PROXY \
    -u NODE_OPTIONS -u NODE_EXTRA_CA_CERTS \
    claude -p "hi"

If that returns in ~2–3s, the cause is one of those injected vars (unset them one at a time to find which).

3. If it persists, try a near-clean env (keep just what auth/PATH need):

env -i HOME="$HOME" PATH="$PATH" TERM="$TERM" claude -p "hi"

A clean-env success confirms it's an inherited variable, not the binary or VS Code's PTY itself.

My leading guess is a proxy variable: VS Code (and some extensions/corporate setups) export HTTP(S)_PROXY into the integrated terminal pointing at a loopback or gateway proxy. Node/undici will route through it and can coalesce many short requests onto one upstream connection — which is exactly what produces "pre-upstream queue is saturated" under retry — while curl's proxy/keep-alive handling differs enough to dodge it. The env diff in step 1 will confirm or kill that quickly. (I'm reasoning from the transport behavior here, not asserting it's definitely proxy — the diff is what makes it certain.)

---

For the maintainers: this is a good repro that the failing path is environment-inherited transport behavior, not request content — identical source=sdk request, identical endpoint, curl fine from both terminals, only the VS Code-spawned process consistently lands on the saturated upstream and burns all 11 retries. Worth checking whether the CLI's HTTP client is honoring an inherited proxy / connection-pooling setting that VS Code injects and Terminal.app doesn't, and whether a 503 pre-upstream queue is saturated should even be retried 11× (it reads like client-side connection coalescing being mistaken for a server rate signal).

Ran the env diff (thanks @yurukusa). Sanitized env | sort from both terminals, then diffed. Headline: the transport vars the theory points at aren't present on either side — no HTTP_PROXY / HTTPS_PROXY / ALL_PROXY / NO_PROXY, and no NODE_OPTIONS / NODE_EXTRA_CA_CERTS in the VS Code env or the native one. So an inherited proxy/TLS variable doesn't look like the cause.

Everything the VS Code integrated terminal injects that Terminal.app doesn't is shell-integration / editor scaffolding, not networking (sanitized; values redacted where sensitive):

CLAUDE_CODE_SSE_PORT=21775
COPILOT_DEBUG_NONCE=<redacted>
GIT_ASKPASS=<redacted>
MallocNanoZone=0
USER_ZDOTDIR=/Users/<user>   ZDOTDIR=/Users/<user>
VSCODE_GIT_ASKPASS_EXTRA_ARGS / _MAIN / _NODE=<redacted>
VSCODE_GIT_IPC_HANDLE=…/T/vscode-git-…sock
VSCODE_INJECTION=1   VSCODE_PROFILE_INITIALIZED=1   VSCODE_PYTHON_AUTOACTIVATE_GUARD=1
__CFBundleIdentifier=com.microsoft.VSCode   __CF_USER_TEXT_ENCODING=0x1F5:0x0:0x0

LANG: en_US.UTF-8 (native) → C.UTF-8 (VS Code)
PATH: VS Code prepends the GitHub Copilot extension's copilotCli/debugCommand dirs + the VS Code app bin

CLAUDE_CODE_SSE_PORT is the only network-ish entry and it's already ruled out (unsetting it / suppressing IDE detection doesn't help). Nothing here is a proxy, a Node HTTP/TLS setting, or anything that should change which upstream the request lands on. (Ignore PWD/OLDPWD differing — I just ran the two captures from different directories.)

Net: this argues against an inherited-env explanation and back toward how the VS Code-spawned process is created, not what it inherits or sends. Decisive next test on my side is the clean-env run — env -i HOME="$HOME" PATH="$PATH" TERM="$TERM" claude -p "hi"; if it still 503-loops with a near-empty environment, env is fully excluded. Will follow up with that.

Clean-env test: still fails. Ran the near-empty environment in the VS Code integrated terminal:

env -i HOME="$HOME" PATH="$PATH" TERM="$TERM" claude -p "hi"

Still hangs and 503-loops (pre-upstream queue is saturated). From Terminal.app it returns in ~2–3s, as always.

So environment variables are fully excluded. With only HOME/PATH/TERM set — no VSCODE_*, no shell-integration vars, no CLAUDE_CODE_SSE_PORT, nothing — the VS Code-spawned process still lands on the saturated path while a native login shell doesn't. Combined with the earlier evidence (identical source=sdk request, curl fine from both terminals, no proxy/NODE_* vars in either env), nothing inherited as an environment variable explains it.

That leaves the process/launch context itself: how the CLI is spawned and parented under VS Code (PTY, parent process tree, inherited fds/sockets) versus a login shell — not its environment and not its request. Worth a maintainer looking at whether the HTTP client's connection behavior depends on that launch context, and (echoing @yurukusa) whether a 503 pre-upstream queue is saturated should be retried 11× at all rather than surfaced.

Resolved — this was my own config, not a Claude Code bug. Closing.

Root cause was a project-local override in this folder's .claude/settings.local.json:

"env": { "ANTHROPIC_BASE_URL": "http://127.0.0.1:8787" }

That routed every request through a local gateway (a queue manager I run on :8787) instead of api.anthropic.com. Its queue was saturated, which is where the pre-upstream queue is saturated 503 and the hang/retries came from — and it only reproduced inside this folder, because that's where the project settings load.

This also unwinds the "VS Code vs Terminal.app" framing in the comments above: that was a directory confound — I ran the native capture from ~ and the VS Code one from the project dir. Terminal.app inside the folder fails identically, and the extension hangs because it operates on the same workspace. curl and the env diff looked clean because the override isn't a shell env var (Claude injects it from the settings file) and curl hit api.anthropic.com directly.

Fix: removed the ANTHROPIC_BASE_URL override; Claude goes direct again and returns in ~2–3s inside the folder. If anything's actionable on the Claude Code side, it'd only be surfacing a gateway 503 sooner instead of an 11× hang — minor. Thanks @yurukusa for the steer. Closing as resolved — not a Claude Code issue.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.