[Bug]: OpenCode admission recovery completes a turn before generation starts

[vedprakash2302]

Before submitting

• I searched existing issues and did not find a duplicate of this confirmed startup race.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Summary

OpenCode prompt-admission recovery can mark a turn completed before generation starts. It finds the submitted user message, reads an empty session-status map twice, and treats that as completion. A later native busy event cannot restore the running state because T3 has already cleared the active turn ID.

The agent continues generating and executing tools while the sidebar no longer shows "Working". This occurred on a remote Linux/WSL environment and is confirmed by that server's provider log and read-only database inspection.

Steps to reproduce

This is timing-dependent. The observed ordering was:

1. Submit a prompt to an OpenCode thread. The observed case was an existing conversation whose provider session started again for this prompt.
2. OpenCode persists the user message before reporting the session as busy.
3. T3's prompt-admission recovery finds that message and receives {} from session.status on two checks before generation begins.
4. T3 emits turn.completed with raw type session.status.recovered and clears the active turn.
5. OpenCode emits native session.status: busy and continues the response, but T3 leaves the session ready with no active turn.

A deterministic adapter regression test could hold the native busy event, make session.message return the submitted user message, return {} from the status requests that trigger admission recovery, then release busy and tool events. The turn should remain active until actual completion evidence arrives. This test has not yet been implemented or run.

Expected behavior

Finding the user message proves admission, not completion. A status map that omits the session during startup must not be enough to complete the turn before generation starts. The sidebar should show "Working" throughout the agent's work.

Actual behavior and captured timeline

All times below are UTC on 2026-09-21, from the affected environment's provider and orchestration logs:

Time	Event
13:07:42.044	T3 emits turn.started.
13:07:43.118	T3 emits turn.completed with raw payload {"type":"session.status.recovered","status":{}}.
13:07:43.493	T3 observes the native user message.updated event.
13:07:43.526	T3 observes native session.status with {"type":"busy"}, about 408 ms after it declared completion.
13:07:43.527	T3 observes the native assistant message.updated event.
Through 13:11:18.219	T3 continues recording tool activity, now with turnId: null.

The read model agrees with the premature completion:

projection_thread_sessions.status = ready
projection_thread_sessions.active_turn_id = null
projection_thread_sessions.updated_at = 2026-09-21T13:07:43.118Z
projection_turns.state = completed
projection_turns.completed_at = 2026-09-21T13:07:43.118Z

T3 also captured the turn checkpoint at that premature completion boundary. This is a server turn-lifecycle problem, not merely a missing sidebar indicator.

Source findings

In apps/server/src/provider/Layers/OpenCodeAdapter.ts, schedulePromptAdmissionRecovery:

• Sets messageObserved when session.message returns the submitted user message.
• Treats an absent session in a valid status map as idle.
• Increments idleStatusConfirmations when isIdle && messageObserved.
• Calls completeOpenCodeTurn after two confirmations, without requiring evidence that generation started or an assistant response completed.

The emitted session.status.recovered payload in the live log identifies this exact completion branch. completeOpenCodeTurn clears context.activeTurnId. The native session.status handler then ignores a busy event when turnId is undefined, which explains why the subsequent busy event did not restore "Working".

These branches are at lines 1375-1399, 1433-1469, 1135-1150, and 2589-2593 in the inspected local checkout, commit ffb46df83a02289d2a3a6630929e2bd03eadebe7. The current checkout still contains the problematic recovery logic.

Impact

The sidebar looks idle while an agent is working. Subsequent tool activity loses its turn association, and checkpoint capture occurs before the work finishes.

Version or commit

• OpenCode session version from the native provider event: 1.18.31.
• Provider/model: OpenCode with github-copilot/gpt-6-astra.
• Source inspected: local checkout at ffb46df83a02289d2a3a6630929e2bd03eadebe7.
• The exact affected remote T3 binary version was not captured. The diagnosis uses its actual emitted provider events and persisted state, rather than assuming that it matches the source checkout.

Environment

Windows desktop client connected to a remote Linux/WSL T3 environment. The incorrect state is present in the remote server's database, independently of the client connection.

Related issues

• [Bug]: OpenCode working/tool-call/thinking activity is not folded; sidebar working indicator is a miss or hit #9214 reports intermittent missing OpenCode sidebar working indicators, alongside a separate timeline-folding concern. This report identifies a specific backend startup race with a captured event sequence. It may explain some occurrences of that symptom.
• [Bug]: OpenCode follow-up sent before the idle event lands is folded into the previous turn #10973 concerns a follow-up submitted before a prior idle event is processed. This occurrence instead completes a newly started turn before its own busy event arrives.
• [Bug]: OpenCode timeout error formatting crashes and skips session recovery #12456 concerns an exception while formatting timeout errors. The completion event here contains an empty recovered status map, not that error path.

Investigation

Investigated with GPT-6 Astra through OpenCode in T3 Code. Private repository names, thread identifiers, host addresses, and conversation content have been omitted. No live state was modified and neither environment was restarted.

[Zzackllack]

Still reproducing on local macOS, captured a clean instance tonight on the latest nightly.

Environment

• T3 Code (Nightly) 0.0.43-nightly.20260927.2365 (commit 94f92a7a386a), macOS 27.0 (26A428), Apple Silicon, local environment
• OpenCode CLI 1.18.32 (Homebrew), spawned by T3 as opencode serve
• Provider/model: OpenCode with openrouter/openrouter/auto
• Trigger: first prompt in a brand-new thread (session started fresh for the thread)

Captured timeline (provider event log, UTC, 2026-09-27)

Time	Event
21:24:33.748	session.started / thread.started — new session ses_f1b3e9eb…
21:24:33.759	turn.started (opencode-turn-c69f363e…)
21:24:34.540	turn.completed, raw payload {"type":"session.status.recovered","status":{}} — 781 ms after turn.started, before any assistant output
21:24:34.963	native message.updated
21:24:34.976	native session.status → {"type":"busy"} — 436 ms after the premature completion
21:24:35.473 – 21:25:08	further busy statuses; streaming message.part.updated, tool activity
21:24:55.836 / 21:24:59.638	canonical tool item.completed events with turnId: null
21:25:08.576	idle — the real turn ran ~35 s

So the completion branch fires 781 ms in, the later busy is ignored (no active turn), and subsequent tool activity loses its turn association — matching the mechanism described in this issue.

Read-model state (state.sqlite)

projection_turns.state        = completed
projection_turns.completed_at = 2026-09-27T21:24:34Z  (turn started 21:24:33.759Z)

Recurrence on the same build

9 short (3–4 s) completed OpenCode turns today between 15:51 and 21:35 UTC across five threads, each consistent with the same admission-recovery race. One adjacent data point: in another thread a turn started at 21:37:10 never received a turn.completed and the session stayed running with an active turn — possibly the complementary side of this lifecycle.

Happy to attach fuller log excerpts (provider event log + server trace) if useful.

[abdelrahman-aboelnour]

Same race reproduced on a second environment.

• T3 Code desktop 0.0.44 (stable), Windows, local server (not remote)
• Provider: OpenCode, model github-copilot/gemini-3.8-flash
• Frequency: 22 of 136 OpenCode turns in the local provider event logs (Sep 28-30) were completed via session.status.recovered

Timeline (UTC, 2026-09-30):

Time	Event
09:57:11.189	turn.started
09:57:12.918	turn.completed, raw {"type":"session.status.recovered","status":{}}
09:57:13.341	native session.status busy (~420 ms after completion), no turnId
09:57:13 - 09:58:47	~37 tool call / message events, all with turnId: null

The UI shows the send button instead of Stop and drops "Working" while the agent keeps running tools. Confirms the installed 0.0.44 bundle contains the same idleStatusConfirmations >= 2 recovery branch. #10805 + #11640 look like the right pair of fixes.

Reported via manual triage by claude-opus-5.5 (OpenCode, in T3 Code).