OpenAI stream intermittently freezes in working state with high CPU and idle HTTPS socket

[riccardo-algorime]

Summary

OpenCode intermittently gets stuck in a "working" state during an OpenAI streaming response. The UI indicates the model is working, but it is not visibly thinking, producing output, or executing tools. The process does not crash; it remains alive and burns CPU until manually restarted.

I captured the process while it was frozen. At the time of capture, the latest OpenCode log entry was an OpenAI stream start, with no further log activity for several minutes. The TCP socket to the remote HTTPS endpoint was still established but had no recent send/receive activity.

Version

• OpenCode: 1.15.10
• Install path: ~/.opencode/bin/opencode
• Binary type: Linux x86_64 ELF
• Latest upstream release at time of report: v1.15.10

Environment

• OS: Linux
• Host timezone during capture: UTC
• Filesystem had free space: /dev/root was 48% used, 33G available
• OpenCode data sizes:
  • ~/.local/share/opencode: 24M
  • ~/.cache/opencode: 94M
  • ~/.config/opencode: 58M

Config shape

Sanitized config shape:

{
  "$schema": "https://opencode.ai/config.json",
  "plugin": [
    "@tarquinen/opencode-dcp@latest"
  ],
  "mcp": {
    "context7": {
      "type": "remote",
      "url": "https://mcp.context7.com/mcp",
      "enabled": true,
      "headers": {
        "CONTEXT7_API_KEY": "***"
      }
    },
    "exa": {
      "type": "remote",
      "url": "https://mcp.exa.ai/mcp",
      "enabled": true
    }
  }
}

The freeze captured below happened in a session that had just used Context7 tools, but the actual stuck point appears to be a subsequent OpenAI stream.

Symptom

Frequency: intermittent, roughly once every few tens of minutes in active use.

Observed behavior:

• TUI shows the model as "working".
• It is not visibly "thinking".
• No new output appears.
• No tool call appears to be running.
• The process does not exit.
• Restarting OpenCode is required to recover the session.

Captured freeze

Snapshot time:

2026-05-24T18:56:50Z

Process state at capture:

PID      STAT  ELAPSED  %CPU  %MEM  COMMAND
2681734  Rl+   18:19    32.8  8.0   opencode

Thread state:

PID      TID      STAT  %CPU  %MEM  WCHAN          COMMAND
2681734  2681734  Sl+   17.7  8.0   ep_poll        opencode
2681734  2681751  Sl+   10.0  8.0   ep_poll        Worker
2681734  2681736  Sl+    3.3  8.0   futex_do_wait  HeapHelper
2681734  2681735  Sl+    0.2  8.0   futex_do_wait  opencode
2681734  2681768  Sl+    0.0  8.0   ep_poll        Worker
2681734  2681755  Sl+    0.0  8.0   ep_poll        HTTP Client
2681734  2681744  Sl+    0.0  8.0   futex_do_wait  Bun Pool 1
2681734  2681743  Sl+    0.0  8.0   futex_do_wait  Bun Pool 0

Open socket at capture:

ESTAB 0 0 10.3.0.4:50426 172.64.155.209:443 users:(("opencode",pid=2681734,fd=31))

Additional ss -tinp data shortly after:

lastsnd:230238
lastrcv:232073
lastack:230237

So the process had an established HTTPS socket, but there had been no send/receive activity for roughly 230 seconds.

Relevant log tail

Current UTC time when checked:

2026-05-24T18:57:18Z

Latest log file:

~/.local/share/opencode/log/2026-05-24T183835.log

Log file mtime:

2026-05-24 18:53:27.938034196 +0000

The log stopped after starting an OpenAI stream:

INFO  2026-05-24T18:53:23 +8ms service=session.processor session.id=ses_1a51a53b2ffeK3pvv67AVr3ck3 messageID=msg_e5b55b1a1002a3wFOXGBnhu9bX process
INFO  2026-05-24T18:53:23 +0ms service=bus type=session.status publishing
INFO  2026-05-24T18:53:23 +2ms service=llm providerID=openai modelID=gpt-5.5 session.id=ses_1a51a53b2ffeK3pvv67AVr3ck3 small=false agent=build mode=primary stream
INFO  2026-05-24T18:53:23 +2ms service=default llm.runtime=ai-sdk llm.provider=openai llm.model=gpt-5.5 llm runtime selected
INFO  2026-05-24T18:53:24 +787ms service=bus type=message.part.updated publishing
INFO  2026-05-24T18:53:25 +862ms service=bus type=message.part.updated publishing
INFO  2026-05-24T18:53:26 +993ms service=permission permission=context7_query-docs pattern=* action={"permission":"*","action":"allow","pattern":"*"} evaluated
INFO  2026-05-24T18:53:26 +5ms service=bus type=message.part.updated publishing
INFO  2026-05-24T18:53:27 +1632ms service=bus type=message.part.updated publishing
INFO  2026-05-24T18:53:27 +4ms service=bus type=message.part.updated publishing
INFO  2026-05-24T18:53:27 +1ms service=bus type=message.updated publishing
INFO  2026-05-24T18:53:27 +2ms service=bus type=message.updated publishing
INFO  2026-05-24T18:53:27 +1ms service=bus type=session.status publishing
INFO  2026-05-24T18:53:27 +0ms service=session.prompt session.id=ses_1a51a53b2ffeK3pvv67AVr3ck3 step=3 loop
INFO  2026-05-24T18:53:27 +34ms service=bus type=message.updated publishing
INFO  2026-05-24T18:53:27 +0ms service=session.tools status=started resolveTools
INFO  2026-05-24T18:53:27 +0ms service=session.tools status=completed duration=4 resolveTools
INFO  2026-05-24T18:53:27 +145ms service=bus type=session.updated publishing
INFO  2026-05-24T18:53:27 +5ms service=bus type=session.diff publishing
INFO  2026-05-24T18:53:27 +12ms service=bus type=message.updated publishing
INFO  2026-05-24T18:53:27 +10ms service=session.processor session.id=ses_1a51a53b2ffeK3pvv67AVr3ck3 messageID=msg_e5b55c32e002z9K2sBXTR8nw0X process
INFO  2026-05-24T18:53:27 +0ms service=bus type=session.status publishing
INFO  2026-05-24T18:53:27 +0ms service=llm providerID=openai modelID=gpt-5.5 session.id=ses_1a51a53b2ffeK3pvv67AVr3ck3 small=false agent=build mode=primary stream
INFO  2026-05-24T18:53:27 +2ms service=default llm.runtime=ai-sdk llm.provider=openai llm.model=gpt-5.5 llm runtime selected

No further log entries appeared by 2026-05-24T18:57:18Z.

Expected behavior

If an LLM stream or provider request stalls, OpenCode should eventually recover, timeout, surface an error, or allow the session to become usable again without requiring a full restart.

Actual behavior

The session remains in a "working" state indefinitely. The log does not advance, the UI does not produce output, and the process continues consuming CPU.

Notes

• This was captured with API keys and tokens redacted.
• The issue may involve provider stream handling, cancellation/timeout handling, or interaction after MCP tool calls. The last completed tool permission before the stuck stream was context7_query-docs, but the observed stall begins after a new service=llm ... stream line.
• I have not yet isolated whether disabling MCP/plugins prevents the issue.

[github-actions]

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

• OpenCode hangs/freezes mid-stream on Starlink satellite internet connection #8002: OpenCode hangs/freezes mid-stream — same symptom pattern (stream starts, message.part.updated events stop, no recovery), though attributed to unstable network
• Tasks/Subagents with Codex / OpenAI are frequently getting stuck with no timeout/retry, which then hangs the session forever #11865: Tasks/Subagents with OpenAI getting stuck with no timeout/retry — same "session hangs forever" outcome with OpenAI provider
• AI model stuck on "thinking" - mainly with GPT models #14732: AI model stuck on "thinking" mainly with GPT models — same visible symptom of indefinite working state
• Sessions permanently stuck after server restart or stream interruption — no startup recovery for orphaned messages/tool parts #19023: Sessions permanently stuck after stream interruption — covers the no-recovery/no-timeout backend root cause

If your issue is distinct (e.g. stable network, specific to post-MCP-tool-call streams), it may still be worth keeping open, but please check the above for overlap.

[jf1x]

+1. This issue starting occurring for me on May 23 , and was not an issue before that. I did not update opencode between May 22 and May 23 either so may be a change on OpenAI's end.

The failure usually happens on the assistant continuation immediately after a previous assistant turn ended with finish=tool-calls.

I reproduced this in pure mode and after setting provider.openai.options.chunkTimeout = 30000 (not sure if that's what this setting is for, but thought I'd try it).

• OS: Windows
• OpenCode: observed in sessions created under 1.15.0; reproduced after updating to 1.15.10
• Node: v22.14.0
• npm: 11.12.0
• Provider: OpenAI
• Models observed:
  • gpt-5.5
  • gpt-5.5-fast

[enshulv]

I’m seeing this as well. For me, this only started happening recently, within the last few days / last week.

At first I thought it might be a version-specific regression, but after rolling back to an earlier version the problem still persisted. Because of that, I suspect something may have changed on the OpenAI side that is triggering this behavior.

The most typical symptom is a complete freeze: there is no error message, no visible thinking, and no further action. It just stays stuck in place, while still appearing to be in a normal running state.

This is very disruptive. It has almost made it impossible for me to write or work reliably, because I cannot predict when it will freeze.

Additional details about my setup:

• Current version: 1.15.10
• Rolled back to: 1.15.9
• Model: gpt-5.5

Version 1.15.9 had previously been working normally for me, but after this issue started happening, rolling back to 1.15.9 did not resolve it.

[imarshallwidjaja]

+1 Happening to me too. Initially thought it was LSP or MCP crashing causing it, but have disabled everything to try repair it to no avail. Seems to only be affecting GPT (normal and fast) models through the codex oauth.

I have the exact same codex account routing through openai-compatible gateway on cursor but do not have the same frozen after tool-call issue.

Current version: 1.15.10

Rolling back to 1.14.X doesnt seem to resolve it.

[rUrU516]

+1 me too and it's pretty annoying. has to interrupt it and re-send the prompt again to resolve it.

ps: turning on the fast mode seems to solve the issue

Current version: latest
os: mac (apple silicon)

[ChanGarcia10]

+1 It's happening to me too. It seems to coincide with the OpenAI problem this weekend. It's still working fine in codex but in Opencode, it seems to get stuck 90% of the time as a subagent.

Current version: latest
windows 11

[Acren]

From what I can see this seems to be a random but frequently occurring OpenAI backend issue, exacerbated by a gap in OpenCode's failure and retry handling.

It seems that sometimes requests to OpenAI will hang indefinitely, not even streaming response headers back. This will cause OpenCode "running" indicators to keep spinning forever while nothing is actually happening.

This is just a guess but I believe this is likely to be much less of an issue for first party Codex apps if they automatically retry on these failures, whereas OpenCode doesn't appear to.

Workaround: I have set OpenCode to run through a local proxy which automatically retries when there are no response headers for 10 seconds, and it has fully resolved the issue for me.

Ideally this is fixed on OpenAI's side, but I think OpenCode could definitely mitigate this with better built-in retry handling that catches response header timeouts.

This is with subscription rather than API key, but I'm not sure if that's relevant or not.

Edit: Looks like difference to Codex could be related to SSE vs sockets rather than retry-handing, however the automatic retry proxy remains an effective workaround.

[arjablc]

+1 the same model works fine on codex-cli but using opencode, I see that it gets stuck in running state quite a lot of time

[PhucTruong-ctrl]

+1 also experience this on opencode go model, the cli feel unresponse and slow as hell

Edit: new session seem to fixed the issue