Sign up
View stargazers12Sign up

[Bug]: Provider reports completion, but T3 run stays active and blocks queued messages.#23008

opened1d agobyRRikEnde

Before submitting

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

Area

apps/desktop

Steps to reproduce

A project hangs indefinitely, and stops responding to the stop button, forcing a T3code restart. Problem occurs both with claude and codex.

Expected behavior

task should complete successfully or at least allow the stop button to work

Actual behavior

task hangs for ever

Impact

Blocks work completely

Version or commit

Version 0.1.1 (fe27e8e3dc12)

Environment

MacOS 27.0.1 (26A434)

Logs or stack traces

shell
1_This task keeps getting stuck. instead of picking up the thread, analyze why the coding agent gets stuck on this. both Opus and Astra got stuck_
2
312:48 PM
4
5The evidence points to **T3’s run tracking as the main cause**, with browser failures and approval waits adding delays. I inspected the stored history and raw provider logs.
6
71. **The models finished, but T3 kept their runs open.** Opus emitted `terminal_reason: completed` at **12:06:08 PM**. Its T3 run remained unresolved until cancellation around **12:36 PM**, while another queued run never started. My previous response also emitted `turn/completed` at **12:37 PM**, yet T3 recorded cancellation at **12:47 PM**. This mismatch explains why switching models didn’t reliably clear the blockage. [Provider log](/Users/[name]/.t3/userdata/logs/provider/events.12e9914b-a7df-4932-b089-d030cf05047c.log:2332)
82. **The preview browser repeatedly failed during verification.** There were eleven 15-second snapshot/evaluation timeouts. Independent Chrome screenshots succeeded. Opus spent several minutes investigating application code before isolating the preview problem, and retried the broken tool too often.
93. **One apparent freeze was an approval wait.** Reading `/tmp/caldebug/[detail.png](https://github.com/tmp/caldebug/detail.png)` was requested at **11:21:03 AM** and returned at **12:05:08 PM**, when its approval completed—about **44 minutes**. That was waiting on a tool permission, rather than model computation.
104. **Switching providers lost useful context.** The new Codex session received your “review the context” message without the earlier implementation history. My reply then incorrectly concluded there was no prior work instead of retrieving it.
11
12The first repair target should be **T3’s handling of provider completion events, run status, and queued-message release**. Approval waits need clear visibility, and browser recovery needs bounded retries.
13
14I found Opus and Codex records here, but no separately identifiable Astra run, so I can’t verify Astra’s exact failure. I made no code or configuration changes.
15
1612:53 PM
17
18_is this a bug in t3 that we need to report or did I **** up?_
19
2012:54 PM
21
22**Yes—this is worth reporting as a T3 bug. You didn’t **** up.**
23
24The strongest evidence is that **both Opus and Codex explicitly reported completion, but T3 kept their runs open until cancellation**. That points to a completion/status synchronization bug and explains the blocked follow-up messages.
25
26The preview timeouts are a second reportable issue. The 44-minute approval wait was expected permission behavior, though T3 should make that waiting state obvious.
27
28A useful bug title: **“Provider reports completion, but T3 run stays active and blocks queued messages.”** Include this thread ID: `12e9914b-a7df-4932-b089-d030cf05047c`.
29
30The logs establish the mismatch; T3’s maintainers will need to determine its exact internal cause.

Screenshots, recordings, or supporting files

t3-provider-events.anonymized.log

Workaround

restart T3Code

JJulius Marminge1d ago

Thanks for the report, and no, this is not you. A run that the provider has finished but that T3 keeps "running" until you cancel is a real bug class, and an open issue already tracks it for Claude: #15197 ("V2 Claude run stays running forever after the CLI reports result/success"). Your case adds Codex, which is useful.

To act on it we need the raw evidence your agent summarised rather than the summary:

  1. The provider events log it cites (~/.t3/userdata/logs/provider/events.12e9914b-….log), at least the ~200 lines around the terminal_reason: completed at 12:06 PM and the turn/completed at 12:37 PM.
  2. The server log (~/.t3/userdata/logs/server*.log) for the same window, including the cancellations at 12:36 PM and 12:47 PM.
  3. Whether the Stop button did nothing at all (no state change) or showed "stopping" without finishing.

Please redact anything private before attaching. The preview-browser timeouts and the 44-minute approval wait are separate behaviours; please keep this issue to the stuck run so it stays actionable.

JJulius Marminge23h ago

Closing as a duplicate of #15197, which tracks the same desktop symptom: the provider finishes, but T3 keeps the run active. I linked your new evidence there, including the Codex completion, queued runs that never started, and Stop requests rejected as “not interruptible.” This is a symptom match, not a claim that both providers share a root cause. No current-main reproduction was performed during duplicate triage.