Repository navigation
[Bug]: OpenCode 2 ACP first turn settles in ~70 ms during provider startup; chat shows 'Worked for 0s' and drops live output #40748
Description
Operating system
Linux
Orca version
1.4.255
Details
Summary
OpenCode 2 native chats settle the turn almost immediately after the first prompt, showing "Worked for 0s" and dropping all live output. The turn keeps running in OpenCode; an external opencode TUI on the same session shows the full response.
This is not #31423 (first prompt rejected) and not #38663 (provider exit). The turn is accepted and completed in Orca, but session/prompt returned end_turn before OpenCode created the user message.
Environment
- Orca 1.4.255 (Linux AppImage, Ubuntu 24.04.5)
- OpenCode 2.2.6 (
opencode2, ACP transport) - Affected chats:
opencode2_4bc4bae6_d457_444b_bb9a_572be7346237(resumed) andopencode2_653312ab_5625_4e02_b250_a309f70f3332(fresh,origin: created)
Reproduction A — resumed session
Native session ses_e3afae31effew41aq8zZaZPUhg.
| Time | Event |
|---|---|
| 11:40:53 | provider-exit, generation e98f6edc, closeCause: user-close |
| 11:41:45.290 | agentSession.send accepted; prompt queued |
| ~11:41:45.47 | ACP provider spawn starts (spawn_to_outcome_ms: 1306) |
| 11:41:46.778 | agentSession.startup ready |
| 11:41:46.784 | Turn running, startedAt: 1794307306784 |
| 11:41:46.851 | Turn completed, outcome: success, completedAt: 1794307306851 (67 ms) |
| 11:41:46.851 | Settlement provider-timeline:…:1:turn-end |
| 11:41:46.862 | OpenCode creates the user message msg_1c50cb556001RkK20z0G1ThkAD |
| 11:41:46.887–11:42:10.495 | OpenCode streams assistant messages and tool calls, then idle: succeeded |
Reproduction B — fresh chat, no resume
Native session ses_e3ad3edc8ffeqSUXqVtX65J8cI, provider handle origin: created.
| Time | Event |
|---|---|
| 12:16:00.718 | agentSession.send accepted; prompt queued |
| 12:16:02.241 | ACP provider handle created |
| 12:16:02.257 | Turn running, startedAt: 1794309362257 |
| 12:16:02.275 | OpenCode model-switched → auto |
| 12:16:02.285 | OpenCode model-switched → auto variant intelligence |
| 12:16:02.326 | Turn completed, outcome: success, completedAt: 1794309362326 (69 ms) |
| 12:16:02.338 | OpenCode creates the user message |
| 12:16:02.368–12:16:29+ | OpenCode streams assistant/tool output and keeps running |
In both cases the send was queued before the ACP provider was ready, and Orca dispatched the prompt as soon as the handle appeared, while the model/effort writes were still settling. The prompt result came back 11–12 ms before OpenCode created the user message.
Root cause
Orca's ACP adapter ends a turn when the session/prompt response arrives (promptResult → finishPrompt → endTurn). In this startup/config-settling window the response can arrive before the turn has actually started. Orca then ignores the later session/update frames because the turn is already settled.
OpenCode side evidence: a direct ACP run of the same /review prompt with the model and effort writes sent back-to-back returned stopReason: end_turn at 3.7 s, while the assistant was still mid-stream; a second run of the same sequence produced no result for 120 s while the turn kept running. The early result is racy, not deterministic.
Suggested fix
- OpenCode: do not resolve
session/promptwithend_turnuntil the turn is complete. - Orca: do not accept a
turn-endsettlement for a prompt until that prompt's user message has been echoed by the provider, or until the turn has produced at least one frame. Drop or reconcile earlier turn-end settlements. - Orca: validate/clear the stored effort when the model changes, so an auto-only effort is never re-applied to a model that does not support it.
Workaround
Send a one-line warm-up first ("hi"), let it finish, then send the real prompt. The second prompt runs on a warm provider with the model/effort already applied.
Activity
paulovlobato commentedon Nov 10, 2026
Cross-reference: the OpenCode-side ordering issue is anomalyco/opencode#63096. The Orca patch in this report is a mitigation for the config-settling window, not a substitute for the OpenCode fix.
paulovlobato commentedon Nov 10, 2026
Root cause confirmed as the OpenCode slash-command path: anomalyco/opencode#54371 and anomalyco/opencode#53914
The failing prompt was
/review ...(the Orca journal holds the raw command), and OpenCode expanded it into the reviewer body server-side. On the command path, OpenCode returnsend_turnbefore joining the turn's event stream, so Orca correctly sees an early end and no later updates are sent. This is not the generic config-settling race the draft patch targeted; that patch does not fix the/reviewcase. The fix must be in OpenCode (PR #49208 / #53914). There is already an Orca 1.4.250 + OpenCode 2.2.5 report in #54371.Workaround: paste the expanded
/reviewbody as a regular prompt. Plain prompts stream normally; only the recognized-command path is broken.AmoabaKelvin commentedon Nov 11, 2026
Thanks for the detailed timings and for tracing it to the command path.
This is an OpenCode bug, so we're not changing Orca for it. When a message starts with a slash command OpenCode recognizes (like
/review), OpenCode's ACP server returnsend_turnimmediately and sends no more updates for that turn, while the command keeps running. Orca ends the turn when OpenCode says it's over, so the chat shows "Worked for 0s" and the reply never shows up. Plain prompts stream normally.I reproduced it on OpenCode 2.2.7, the latest release:
/reviewended in 9 ms with no updates for the next 60 s, while OpenCode ran the review for about 40 s. The upstream issue is anomalyco/opencode#54371, and I've added this repro there.Workaround until OpenCode fixes it: paste the expanded prompt as plain text instead of typing the slash command.
Closing here as an upstream issue. Please follow anomalyco/opencode#54371 for the fix.