[Bug]: Anthropic web-search bridge holds a turn for the full 200s response-header deadline on a healthy account and reports only a generic timeout #6699

Client or integration

Codex App

Area

Tools / MCP / web search

Summary

When a web-search turn is routed to an Anthropic (Claude) model, the web-search bridge can stall for the full 200 s response-header deadline and then end the turn with a generic timeout, even though the same account answers a direct API call in under 2 s. On 2026-10-07 the local usage log recorded 142 such turns on a single account, every one of them at ~200,0xx ms, while the client showed a hung "thinking" state and produced no output.

Expected: a stalled upstream fetch should surface the underlying condition (and/or fail over to another eligible account) well before 200 s, instead of holding the whole turn.

Reproduction

1. Run the proxy with an Anthropic account pool (round-robin), and route a Claude model through it.
2. From Codex App, issue a prompt that triggers web search (the web_search tool) on a routed Anthropic model, e.g. anthropic/claude-sonnet-5-5.
3. Observe: the turn produces no output for over three minutes; the client shows only a thinking indicator; the turn then ends with 504 Gateway Timeout.

Local usage log row shape (~/.opencodex/usage.jsonl), 142 rows on 2026-10-07:

provider      anthropic-p8c2630
model         claude-opus-5-5 / claude-sonnet-5-5
status        504
durationMs    200007 .. 200060
failureStage  headers-only
failureCause  upstream-fault
upstreamError "Provider response-header timeout after 200000ms during web-search"
attempts[0]   sendCount 1, recoveryKinds []

The message is produced by src/web-search/loop.ts:621 using connectTimeoutMs, which defaults to 200000 ms.

Control measurement taken during the same window: a direct POST https://api.anthropic.com/v1/messages with the same stored OAuth token returned HTTP 200 in 0.4–2.0 s, and GET /api/oauth/usage returned 200. So the account was reachable and healthy while the bridge was timing out.

Not yet consistently reproducible on demand: the failures clustered in one time window (2026-10-07 03:34–10:15 local). I could not reproduce it in isolation afterwards.

Version

2.79.0

Operating system

macOS 26.5.2 (build 25F84), arm64

Provider and model

anthropic / claude-opus-5-5 (also claude-sonnet-5-5)

Logs or error output

# Codex App surfaces:
unexpected status 504 Gateway Timeout: Provider response-header timeout after 200000ms during web-search, url: http://127.0.0.1:10100/v1/responses

# ~/.opencodex/usage.jsonl (representative row)
{"provider":"anthropic-p8c2630","model":"claude-opus-5-5","status":504,"durationMs":200021,
 "failureStage":"headers-only","failureCause":"upstream-fault",
 "upstreamError":"Provider response-header timeout after 200000ms during web-search",
 "attempts":[{"ordinal":1,"status":504,"durationMs":200007,"sendCount":1,"recoveryKinds":[]}]}

# ~/.opencodex/service.log around the window
[web-search-loop] done — 3 searches, 2 iterations, 195386ms
[web-search-loop] cancelled — 3 real searches, 0 placeholders, 195435ms
[anthropic-pool] 429 on <account>; failing over to <account>
[anthropic-pool] no eligible replacement; returning 429

Redacted configuration

{
  "anthropicAccountPool": {
    "enabled": true,
    "autoSwitchThreshold": 99,
    "strategy": "round-robin",
    "stickyLimit": 1,
    "quotaWindow": "weekly"
  }
}

No connectTimeoutMs override is present in ~/.opencodex/config.json, so the 200000 ms default applies.

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

Related/earlier report closed by the automated check for missing fields: #6697.