# \[Bug\]: Provider reports completion, but T3 run stays active and blocks queued messages\. · Issue \#23008 · pingdotgg/t3code

[View on GitCafe](https://git.cafe/pingdotgg/t3code/issues/23008)

Repository: [pingdotgg/t3code](https://git.cafe/pingdotgg/t3code)

Visibility: public

State: completed

Priority: 0

## Description

[Discussion and activity](https://git.cafe/pingdotgg/t3code/issues/23008)

---

### Before submitting

- [x] I searched existing issues and did not find a duplicate.
- [x] 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
_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_

12:48 PM

The 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.

1. **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)
2. **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.
3. **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.
4. **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.

The 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.

I 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.

12:53 PM

_is this a bug in t3 that we need to report or did I **** up?_

12:54 PM

**Yes—this is worth reporting as a T3 bug. You didn’t **** up.**

The 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.

The preview timeouts are a second reportable issue. The 44-minute approval wait was expected permission behavior, though T3 should make that waiting state obvious.

A useful bug title: **“Provider reports completion, but T3 run stays active and blocks queued messages.”** Include this thread ID: `12e9914b-a7df-4932-b089-d030cf05047c`.

The 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](https://github.com/user-attachments/files/33779968/t3-provider-events.anonymized.log)

### Workaround

restart T3Code