Repository navigation
Chat shows 'working...' indefinitely after opencode CLI already finished responding #2644
Description
Activity
Correction: this is on Mac Intel (x64), not Apple Silicon.
Reacted by JeremyThis is a regression — the issue appeared after updating to v0.0.23. It was working fine in the previous version.
Reacted by Jeremy, Rahul Sharma, Francis Saah and Sree NarayananAlso encountering this issue running t3 webui using WSL on Windows 10.
T3 Code version: 0.0.23 (Alpha)
OpenCode v1.14.48i think i've fixed this for myself? let me know if its still doing it and ill improve my PR #2666
Reacted by Sree NarayananI can confirm that it also happens on Apple silicon
Correct. I have been using T3 on M4, and it only happens on opencode models/chats.
One of my chats showed 'Working' for 17 hours.i use opencode integration t3 code (m4, v0.0.23) and it's really bad on how broken it is. this looks like the eventloop around opencode sdk is not handled properly.
here's a side by side video
Cap.2026-05-13.at.16.09.04.mp4
the chat session has ended and t3 code still shows working x min, y sec
i use opencode integration t3 code (m4, v0.0.23) and it's really bad on how broken it is. this looks like the eventloop around opencode sdk is not handled properly.
...
- closing and reopening t3 code doesnt end the chat session
- clicking on the stop button doesnt end the chat either
Screen.Recording.2026-05-13.at.4.25.21.PM.mov
@eersnington are you able to check out that PR i made and see if it fixes the issues you are having? #2666
its fixed it for me, but im only one user so would be helpful to know if its still happening for others so i can make it a better PR?
@justsomelegs > @eersnington are you able to check out that PR i made and see if it fixes the issues you are having? #2666
great timing, i was actually taking a look at your PR right now and getting my clanker to look through opencode sdk as well. i'll build and test it soon
Same for me (mac m1 Max)
Hitting this on Windows 11, T3 Code (Alpha) 0.0.23, opencode 1.14.48. Reproduces with the GitHub Copilot subprovider as well (not just Ollama), across multiple models (Claude Haiku 4.5, Opus 4.7, Opus 4.7 1M internal), on both short ("test", ~4s, finish=
stop) and long turns (5 tool-call steps, ~30s, finish=stop). Always the same: response lands in~/.local/share/opencode/opencode.db(verified by query), T3 UI spins "Working…" forever, no events ever reach the renderer.Smoking gun in
~/.local/share/opencode/log/<session>.log— every single session:service=bus type=* subscribing service=server event connected service=bus type=* unsubscribing ← ~3 ms later, always service=server event disconnectedT3's own trace (
~/.t3/userdata/logs/server.trace.ndjson) confirmsopencode.event.subscribereturnsSuccessin ~0.4 ms — way too fast for a real SSE stream — suggesting the HTTP client is consuming the SSE response as one-shot instead of holding the connection open. After that initial tear-down T3 never reconnects to/event, so it misses everymessage.part.delta,message.updated, andsession.idlefor the rest of the turn.Polling the REST API (
GET /session/<id>/message) returns the completed assistant message immediately, so the data path is fine — only the event/SSE path is broken.Stuck threads have to be cleared by killing T3 and deleting the thread row + its events from
~/.t3/userdata/state.sqlite(tables:projection_threads,projection_thread_sessions,projection_turns,provider_session_runtime, andorchestration_eventswhereaggregate_kind='thread').Happy to test the latest nightly (0.0.24-nightly) if a fix is in flight.
- marked OpenCode tab: assistant messages save to opencode.db but never render in UI #2652 as a duplicate of this issue
on Jun 9, 2026 - marked [Bug]: OpenCode provider freezes on first message — SSE events silently dropped #2691 as a duplicate of this issue
on Jun 9, 2026 I get the same exact issue when using Grok Build. I have a chat in the working state for the past 17 hours on the latest version.
Can confirm this still happens to me for OpenCode on Apple Silicon.
I think I am having this same issue.
Nix OS Unstable
AMD x64 CPUT3Code 0.30.0
Opencode 1.18.9
Possible unconnected:
From running tests on a repo that uses
podman run, it also seems to be resulting in a lot of orphaned processes somehow?
These processes eventually resolve, but take way longer than if I manually run the aforementioned tests.
Still hitting this on Windows with opencode CLI 1.18.x: the underlying session completes (verifiable via CLI session status) but T3 stays on working... indefinitely, and Stop does not clear it. Only fix is killing T3 and clearing the stuck thread rows from state.sqlite. Noting that #2666 was closed unmerged, so there is currently no fix in flight. Happy to test a nightly or scope a minimal reconcile PR if maintainers want one.
Description
After updating to the latest version, when sending a chat message in the T3 Code desktop app, the status shows "working..." indefinitely. However, checking the underlying opencode CLI session directly shows the response has already been completed.
Steps to Reproduce
Expected Behavior
T3 Code should detect when the opencode CLI session has finished responding and update the UI accordingly (stop showing "working...").
Actual Behavior
"Working..." status persists forever, making the UI unusable.
Environment
Additional Context
Issue appeared after a recent update. The underlying agent (opencode) is functioning correctly — responses complete successfully via CLI. The problem is in T3 Code's detection/communication with the opencode CLI process — it doesn't seem to recognize when the session has finished.