Known issue: sessions using openai/gpt-5.5 may fail with "Execution timed out (stuck processing)" (upstream opencode bug)

[ColeMurray]

Status

🟡 Known issue — investigating an upstream fix. This is a heads-up so users
can recognize the symptom and apply the workaround below.

Symptom

Sessions running on openai/gpt-5.5 (especially with reasoning_effort: "xhigh")
intermittently fail with:

Execution failed: Execution timed out (stuck processing)

In the session timeline, the model appears to be "thinking" for ~10 minutes,
then the run is marked failed and the sandbox is shut down. The bridge logs
show bridge.disconnect reason=session_terminated detail=HTTP 410 shortly
after.

This affects sessions triggered from any path (web UI, GitHub bot, Slack bot,
Linear bot) and is not specific to any one customer.

Root cause

The hang originates upstream in opencode, not in background-agents. Tracked in:

• anomalyco/opencode#29129 — primary tracking issue (42+ comments, open)
• anomalyco/opencode#21173 — code-level root-cause analysis
• anomalyco/opencode#29187 — gpt-5.5 mid-stream EOF
• anomalyco/opencode#11865 — original (Feb 2026) report

In short:

1. opencode awaits the first byte from the OpenAI Responses API. With
   gpt-5.5 + xhigh reasoning, time-to-first-token can be very long.
2. opencode has no default first-byte / idle-stream watchdog. The Bun-runtime
   AbortSignal.timeout() is broken for streaming fetches, so even configured
   timeouts don't fire reliably.
3. The OpenAI Responses API does not always send a TCP FIN after terminal
   stream events, so opencode keeps the read open indefinitely.
4. The control plane has a 10-minute sandbox-inactivity watchdog as
   defense-in-depth. It fires, fails the message with the "stuck processing"
   string, and tears down the sandbox.

The user-visible error wording is misleading — this is not the 90-minute
execution timeout. It is the 10-minute inactivity timeout reusing the same
error string. We'll be improving this label.

Affected configurations

• Model: openai/gpt-5.5 (some reports also on gpt-5.4, gpt-5.4-mini)
• Reasoning effort: observed most commonly with xhigh, also reported on
  high
• opencode version: present in every version we've tested (1.1.48 through
  1.15.10). Downgrading does not resolve it.

Workarounds

If you are blocked by this:

1. Use a different model for now — Anthropic Claude models (e.g.
   anthropic/claude-opus-4-7) are not affected by this upstream bug.
2. Lower reasoning_effort — medium or high is far less prone to the
   long time-to-first-token that triggers the hang.
3. Retry the prompt — the hang is intermittent; a new session usually
   recovers.

We'll add a more reliable in-product mitigation as soon as an upstream fix is
available.

What we're doing

• Tracking anomalyco/opencode#29129
  for the upstream fix.
• Evaluating an in-tree mitigation (HTTP-layer proxy with a header-read
  timeout) that several upstream users have confirmed effective as a stopgap.
• Improving the user-visible error wording so the inactivity-timeout path
  doesn't surface as "Execution timed out (stuck processing)."

[carter-smalls]

Probably an OpenAI timeout situation. npx ai-doctor can point out missing timeout guards and unprotected requests.