[Bug]: acpRegistry runs complete in milliseconds with zero items while the agent keeps executing queued turns — thread silently unresponsive, all output dropped

The fault sits in the acpRegistry provider driver under apps/server, which maps each session/prompt to a run and drops session/update notifications when no run is open. Start by reading the code that resolves a prompt and closes its run, then the events.<threadId>.log path it writes to. Done means a run stays open until the agent's turn ends, or a queued prompt is marked queued/failed rather than completed with zero items; a regression test should cover the steering collision.

Before submitting

• I searched existing issues and did not find a duplicate. Closest related: #34267 (ACP providers offer Steer but fail with "does not support active-run steering") and #23919 (Codex queue turns never appear in the thread) — neither covers this acpRegistry failure mode.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

Observed on a long-lived thread (~640 items, 17 runs) driven by an ACP Registry provider. Reconstruction from logs:

1. Thread runs on provider instance acpRegistry_kimi_code (Kimi Code CLI as ACP agent), model aone/qwen3.8-max, runtime mode full-access. A run is in flight (agent streaming LLM steps and tool calls).
2. While that run is still active, send a steering message to the thread from the web UI.
3. The agent ends the in-flight turn early (its session/prompt resolves "succeeded" mid-reasoning; the last reasoning item is truncated mid-sentence). T3 then immediately delivers the steering message as a fresh session/prompt — and from this point on, every session/prompt for the thread resolves in 6–42 ms regardless of content.
4. Send further user messages to the thread. Each one creates a run that is marked completed within tens of milliseconds with zero provider items.

Expected behavior

• A run stays open until the agent's turn for that prompt actually ends, and all provider output (reasoning, tool calls, assistant messages) is attached to the run and visible in the thread.
• If a prompt cannot be delivered or is queued behind an in-flight turn, the run should show a queued/blocked/failed state — never completed with zero items and no error.

Actual behavior

• Every run after the steering collision is marked status: completed in 37–83 ms (requestedAt→completedAt) with zero items. The thread reports activeRunId: null, empty queue, pendingRequestCount: 0 — it looks healthy and idle.
• Meanwhile the agent session is fully alive: it consumes every queued prompt as a full turn at its turn boundaries (dozens of LLM steps per turn, tool calls, git commits, file writes over 15+ minutes). None of that output ever reaches the thread — all session/update notifications for those turns are dropped because no run is open to attach them to.
• The agent-side session state.json lastPrompt field is updated with each new message (proof of delivery into the agent), and its updatedAt matches the agent's next turn start.
• Net effect: the thread becomes permanently and silently unresponsive from the user's point of view, while the agent invisibly keeps receiving and executing every message. The user gets no indication anything is wrong.

Impact

Major degradation or frequent failure

Version or commit

t3 v0.1.9 (linux-x64), runtime service-state protocol 3, activeVersion 0.1.9

Environment

Linux x64 headless server host; T3 server + web UI. Provider: acpRegistry_kimi_code (Kimi Code CLI ACP agent), model aone/qwen3.8-max, options thinking=max mode=yolo. Affected thread 8596cad7-de97-40ef-b958-4848be7edff9, agent session session_da355b67-a123-4b67-b0d4-74f9cdf81170. All timestamps below are UTC on 2026-11-13.

Logs or stack traces

T3 provider event log (~/.t3/userdata/logs/provider/events.<threadId>.log) — the collision at 12:33:49 and every prompt afterwards acking in milliseconds:

12:31:43.358  session/prompt started                     (run 14)
12:33:49.860  user steering message recorded             (attached to run 14)
12:33:49.879  session/prompt succeeded                   (run 14 turn ended mid-reasoning;
                                                          last reasoning item truncated mid-sentence)
12:33:49.913  session/prompt started                     (steering redelivered as fresh prompt)
12:33:49.955  session/prompt succeeded                   (42 ms — yet the agent's turn 15 that this
                                                          prompt started kept running until 12:36:50)
12:34:53.921  session/prompt started   (run 15)
12:34:53.927  session/prompt succeeded                   (6 ms, zero items)
12:35:06.670  session/prompt started   (run 16)
12:35:06.676  session/prompt succeeded                   (6 ms, zero items)
12:44:58.611  session/prompt started   (run 17)
12:44:58.621  session/prompt succeeded                   (10 ms, zero items)

Agent-side session log (~/.kimi-code/sessions/<workspace-dir>/<session>/logs/kimi-code.log) — continuous turns across the same window; the agent never stopped and consumed each queued prompt at its turn boundary:

12:33:37.068  llm request   turnStep=14.5    (run 14 in flight; this step's response never
                                              completes — turn ended by the steering collision)
12:33:49.922  llm request   turnStep=15.1    (turn 15 starts 9 ms after the 42 ms prompt ack;
                                              steps 15.1–15.5 run until 12:36:50)
12:36:50.443  llm request   turnStep=16.1    (turn 16 = next queued prompt; 17 steps,
                                              runs until 12:47:42)
12:47:42.903  llm request   turnStep=17.1    (turn 17 = next queued prompt)
12:51:47.845  llm request   turnStep=18.2    (still executing ~7 min after run 17 was
                                              marked "completed" with zero items)

Agent session state.json: lastPrompt equals the run-17 message text; updatedAt = 12:47:42.893Z == turn 17.1 start (12:47:42.903Z) — queued prompts are consumed at turn boundaries.

T3 thread record (t3_thread_read): runs 15/16/17 status: completed, startedAt→completedAt = 37/54/83 ms, no assistant/reasoning/tool items; itemCount frozen at 644 while the agent executed turns 15–18 (dozens of LLM steps, one 6,285-token output step, a git commit, and dozens of generated files in the thread's worktree — all invisible in the thread).

Interpretation. Two faults compound:

1. Agent side (primary): the ACP agent resolves session/prompt before the turn ends — immediately when the prompt is queued behind an in-flight turn, and (for the 12:33:49.913 prompt) ~40 ms into a turn that then ran for 3 more minutes. Per ACP semantics the request should stay open until the turn completes with a stop reason.
2. T3 side: the acpRegistry driver treats that instant resolve as a completed run (zero items, no anomaly flagged), and afterwards drops the session's continuing session/update stream because no run is open to attach it to. T3 also keeps offering steering on this provider (cf. #34267); the "end turn, then send steering as a fresh prompt" fallback is what broke the run↔turn mapping here. A sanity check — e.g. a "completed" run with zero items while the session is still emitting updates, or updates arriving for a session with no open run — would catch this and could re-attach or at least surface the desync instead of showing a healthy idle thread.

Once desynced, the thread never recovers: every subsequent message repeats the millisecond no-op run.

Workaround

None that restores visibility. Messages sent to the thread still reach and are executed by the agent (verified via agent-side logs and worktree effects), so the loop kept running — but the user sees nothing and gets no replies. We are monitoring the agent session log and the git worktree out-of-band to observe real progress. We deliberately avoided freshContext/session restart because the live agent session is still working in the same worktree, and a restart would create two concurrent sessions writing to it.