SSE stream silently dropped mid-response hangs session/subagents forever — chunkTimeout has no default on the openai path

[Jaaaky]

Description

Subagents running on a ChatGPT subscription (providerID openai, codex auth, model
gpt-5.6-sol) freeze mid-run and never recover. The parent session stays busy forever,
queued prompts are never delivered, and the only escape is interrupting the whole
session, which kills all subagents.

I caught this live on two TUI instances and diagnosed it. Both processes were blocked
on ESTABLISHED connections to chatgpt.com's edge that had been dead-idle for ~50
minutes. The flow was silently dropped along the path (CDN/NAT idle timeout, no
FIN/RST ever delivered):

ESTAB 0 0 10.x.x.x:53326 104.18.32.47:443  lastsnd:2907584 lastrcv:2893284  (no keepalive timer)

opencode.log stops at the request start and never logs another line for that session:

23:54:03 message=stream providerID=openai modelID=gpt-5.6-sol ... agent=security-auditor mode=subagent

Why it hangs forever (v1.18.3, code identical on dev):

• wrapSSE in packages/opencode/src/provider/provider.ts is only armed when the
  chunkTimeout provider option is set. There is no default for any provider.
• Bun's own fetch timeout is explicitly disabled: timeout: false (provider.ts:1758,
  ref Respect timeout passed to fetch oven-sh/bun#16682).
• The openai headerTimeout default (10s, provider.ts:35,208) only bounds
  time-to-headers. After headers, reader.read() blocks with nothing above it.
• Both retry layers (ai-sdk maxRetries and SessionRetry.policy in processor.ts) are
  error-driven. A silent stall throws nothing, so they never fire.

Verified workaround: setting provider.openai.options.chunkTimeout (e.g. 120000) in
opencode.json. When it fires, MessageV2.fromError maps the ResponseStreamError to a
retryable APIError, the turn auto-retries and the subagent resumes with full context.

So a small fix seems possible: add a default chunkTimeout for openai next to
OPENAI_HEADER_TIMEOUT_DEFAULT, and/or enable TCP keepalive on provider sockets.

Also verified: for an already-hung process, killing just the dead socket with
sudo ss -K dst <edge-ip> dport = 443 unsticks it without restarting opencode and
the subagent auto-resumes — the app recovers fine once the socket errors, it just
never notices a silent stall on its own.

Related: #11865, #33028, #29129.

Plugins

@slkiser/opencode-quota

OpenCode version

1.18.3

Steps to reproduce

1. Start a task-tool subagent on the openai/ChatGPT subscription path with a
   long-reasoning model. Wait for message=stream providerID=openai in the log.
2. Silently blackhole that connection mid-stream to simulate a CDN/NAT idle drop
   (no RST, packets just vanish):
   sudo iptables -A INPUT -p tcp --sport 443 -s -j DROP
   sudo iptables -A OUTPUT -p tcp --dport 443 -d -j DROP
3. Subagent spinner runs forever, prompts queue and are never delivered, no timeout
   or retry ever fires. ss -tinoe shows the socket idle with no timer armed.
4. Repeat with provider.openai.options.chunkTimeout set: the same scenario aborts
   after the timeout and auto-retries successfully.

Screenshot and/or share link

No response

Operating System

Debian 13, Linux 6.12.90+deb13.1-amd64

Terminal

tmux over SSH

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Tasks/Subagents with Codex / OpenAI are frequently getting stuck with no timeout/retry, which then hangs the session forever #11865: Tasks/Subagents with Codex/OpenAI frequently getting stuck with no timeout/retry, hanging the session forever (same provider path, same symptom)
• OpenAI stream intermittently freezes in working state with high CPU and idle HTTPS socket #29129: OpenAI stream intermittently freezes with idle HTTPS socket — log stops at stream start, process stays alive indefinitely (nearly identical diagnosis and root cause)
• [BUG] Subagents hang indefinitely after quick bash tool call - stream never times out (Aborted, stack=undefined) #33028: Subagents hang indefinitely after bash tool call — stream never times out (same missing-timeout root cause)

Your issue adds valuable specifics (the chunkTimeout code path analysis, wrapSSE only armed when the option is explicitly set, and the ss -K workaround), which may help move those issues forward.

[VINODvoid]

Dug into this on dev — the diagnosis holds up. In packages/opencode/src/provider/provider.ts, wrapSSE only kicks in if a positive chunkTimeout is passed (L38), otherwise it hands the SSE body straight back unwrapped. The openai provider sets a headerTimeout (L208) but never a chunkTimeout, and the header one only covers time-to-headers. So once headers land, a dead stream just sits on reader.read() forever, nothing throws, and none of the retry layers ever get a chance to fire. Lines up with what you saw.

Good news is the recovery already works when chunkTimeout is set — wrapSSE throws ResponseStreamError, it gets mapped to a retryable error, and the turn retries on its own. So it's genuinely just a missing default.

Fix is basically adding one next to the header default:

const OPENAI_CHUNK_TIMEOUT_DEFAULT = <value>   // near L35
options: { headerTimeout: OPENAI_HEADER_TIMEOUT_DEFAULT, chunkTimeout: OPENAI_CHUNK_TIMEOUT_DEFAULT }  // L208

Two things I'd rather not guess at, since this hits every OpenAI user. First, the value — it triggers on silence between chunks, and reasoning models can go quiet for a while mid-thought, so too low and you'd kill real streams. Your 120s seems safe; I'd maybe go 180s to be safe. Second, scope — meta, xai, github-copilot and azure all stream through the same path with no timeout either, so should this default cover just openai or all of them?

Once that's decided I'm happy to open a PR with a test for it.