[Bug] v0.8.0: setGlobalDispatcher(EnvHttpProxyAgent({ bodyTimeout: 0, headersTimeout: 0 })) disables ALL HTTP timeouts — a never-answering provider hangs the turn indefinitely

[claudegoogl-sudo]

Affected area

AI providers and models
Coding agent and CLI

What happened?

The CLI bundle installs a global undici dispatcher with all HTTP timeouts disabled:

setGlobalDispatcher(new EnvHttpProxyAgent({ bodyTimeout: 0, headersTimeout: 0 }));

(dist/bundle/cli-main-JLBZR3DA.js, same line in the unbundled dist/cli-main.js, v0.8.0 / UA 2.1.258.)

With the dispatcher at 0/0, any provider request that is accepted but never answered hangs the turn indefinitely, because:

• the Anthropic SDK client used for OAuth sessions (new Anthropic({ apiKey: null, authToken, baseURL, ... }), no timeout, no custom fetch) only bounds time-to-headers via its per-request default (10 min) — and a stalled response body (idle SSE stream) is unbounded;
• credential-path fetch calls that carry no AbortSignal (e.g. the OpenAI Codex token exchange/refresh in the bundled OAuth module) are fully unbounded.

Production observation (headless, Linux, v0.8.0): a single anthropic-messages call emitted turn_start and then produced no events for 3 h 13 m; the request eventually completed with a 401 OAuth access token has expired — i.e. the client had been parked on the response the entire time. The CLI's own auto-retry then recovered the session in under 6 s once the failure finally surfaced. Related symptom report: #2093.

Steps to reproduce

Deterministic (no usage-window dependence):

1. Start a mock provider that accepts the TCP connection and the POST body but never responds (no status line, no body):

require("node:http").createServer((req, res) => {
  req.resume(); // read the body, then hold the socket open forever
}).listen(0, "127.0.0.1", () => console.log("PORT", server.address().port));

2. Point a custom provider at it via ~/.prime/agent/models.json (api: "anthropic-messages", baseUrl: http://127.0.0.1:<port>).
3. Run the CLI headless (--mode json) with that provider and any prompt.
4. Observe: turn_start is emitted, then silence — no message_end, no error, no retry, for as long as you care to wait (we observed 3 h 13 m in production before the provider finally answered).

Expected behavior

• A provider request whose response never arrives should fail in a bounded time (e.g. headersTimeout: 60_000), surfacing the CLI's normal provider-failure path so the existing auto-retry can take over.
• An idle SSE body should trip a body-idle timeout (e.g. bodyTimeout: 600_000) — reset on every chunk, so healthy long streams are unaffected.

Actual behavior

With bodyTimeout: 0, headersTimeout: 0 the request waits forever; the turn emits nothing; the only recovery is the provider eventually responding or the process being killed externally.

Prime Agent version

0.8.0

Installation method

npm package

Operating system

Linux

Operating system version

Ubuntu 24.04 (kernel 6.8)

CPU architecture

x86_64 / amd64

Shell and terminal

bash, non-interactive headless (CLI driven by automation)

Additional context

We validated the fix on a vendored copy by changing only the two numeric arguments:

setGlobalDispatcher(new EnvHttpProxyAgent({ bodyTimeout: 600000, headersTimeout: 60000 }));

Measured against the never-responding mock above:

• each hung request is abandoned by the client at ~60 s (UND_ERR_HEADERS_TIMEOUT, surfaced as the CLI's "Request timed out." provider error) instead of hanging — verified from the mock side: the client disconnects at ~60 s while the mock would happily hold the socket open;
• the CLI's stock internal retry ladder (3 attempts) surfaces the turn-level error at ~3 × 60 s, after which the built-in auto-retry recovered the same session when the provider answered;
• a 45 s-cadence SSE stream ran 20+ minutes with zero spurious body timeouts at bodyTimeout: 600_000;
• because npm-undici's setGlobalDispatcher writes the shared Symbol.for("undici.globalDispatcher.1") registry slot that Node's global fetch also reads, this additionally bounds the credential-path fetches that have no AbortSignal of their own (e.g. the bundled OpenAI Codex token refresh; the Anthropic OAuth postJson already carries AbortSignal.timeout(30_000)).

If zero-timeout semantics are intentional for some environment (very slow proxies?), making the two numbers configurable (env vars) would keep that possible without defaulting every hop to unbounded.