[Bug]: Threads get stuck on "waiting for 0s"

[merlinnot]

Before submitting

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

Area

Not sure

Steps to reproduce

1. Start the app with t3 v0.0.11 and codex-cli 0.114.0 (I'm using the web version and latest Chrome).
2. Type a message in any thread.
3. Wait for the response to "never complete".

I see some messages from the agent, but when it completes the answer, I still can't send new messages. I also can't stop the agent. Browser refresh fixes it - after a refresh I can send new messages. It never gets out of this state:

Expected behavior

I should be able to stop the response and send messages immediately after sending a previous one.

Actual behavior

The UI seems to be stuck.

Impact

Major degradation or frequent failure

Version or commit

v0.0.11

Environment

running t3 on a Linux server I access remotely

Logs, stack traces, or screenshots

No errors on the t3 back end, I can see clear logs that turns are finishing fine.

This is what Codex told me:

Evidence: For thread cbebfd8c-f2fa-4fc9-9198-3bebfc5711f8, the provider log shows normal completion for turn 019ce8b1-ba50-7081-9425-58654c76c223:

codex/event/task_complete
thread/status/changed with idle
turn/completed with status: completed and error: null
Root cause: The runtime/orchestration state can retain a stale activeTurnId even after the session is ready. Later turn.started / turn.completed events are then rejected by the strict lifecycle guard as conflicting with the stale active turn, so projections stop updating correctly. This leaves thread/session state inconsistent and the UI can keep rendering the composer as “working”.

Observed stale state:

projection_thread_sessions had status = ready but a non-null old active_turn_id
projection_turns contained an orphan pending row with turn_id = null
projection_threads.latest_turn_id could lag behind the newest completed turn
Likely fix: In the runtime lifecycle guard, only treat activeTurnId as authoritative while session status is actually running, and clear stale running/latest-turn UI state when the session transitions back to ready.

Workaround

Refresh the page.

[FleetAdmiralJakob]

Same issue, but for me it works after like 20 seconds of nothing happening. But since for you it seems to not work at all it maybe is a different error.

[tmm22]

I also encountered this bug, although I am not sure why. It appears to happen randomly.

[FleetAdmiralJakob]

Yeah, probably has nothing to do with the version you're using. I'm using the Windows app while @merlinnot uses the web app

[dbalders]

How often is this happening to you all? Been trying to replicate it, but haven't been able to get it to happen. Is there a specific pattern that triggers it? or just happens randomly mid thread?

[FleetAdmiralJakob]

Nah, not mid thread, for me it doesn't happen once a thread is initiliased but happens after the first message is sent once per thread.

[merlinnot]

In my case I had some threads where this was happening on every single message (literally 100%), while other threads worked just fine.

[greendra8]

On Linux. Happened for me when I closed T3 Code mid response. After opening it the thread that was responding was stuck like this.

[xsploit]

it's happening to me alot im trying to fix it rn
Looks like it's fixed

From Codex: I fixed it in two layers, because the bug was split between backend state and frontend rendering.

In the backend lifecycle guard, ProviderRuntimeIngestion.ts was treating activeTurnId as authoritative even when the session had already gone back to ready. That let stale session state block later turn.started and turn.completed events. I changed it so activeTurnId only matters while the session status is actually running. I added a regression test for that stale-ready case in ProviderRuntimeIngestion.test.ts.

Then I fixed the read model so the UI stops pretending a turn is still active after the session has already ended. In projector.ts and store.ts, when a session leaves running, any stale latestTurn.state === "running" now gets reconciled to completed, interrupted, or error based on the real session status. That’s what prevents the composer from staying stuck on Working.

[satchlj]

this is happening to me in certain threads in the macOS desktop app with Codex.

• the send button stays in spinner mode instead of returning to the normal send arrow
• the stop button never becomes available
• the “working for N seconds” indicator freezes
• I can no longer send another message in that thread
• the model may still continue emitting assistant messages even though the UI appears stuck

The only reliable workaround I’ve found is quitting and reopening the app.

I inspected the persisted thread state for one affected thread:

• session status was ready
• but activeTurnId was still set to an older completed turn

After that happened, newer assistant messages and later completed turns were still being projected for the same thread, but the session lifecycle no longer advanced correctly.

Codex thinks this is in the provider runtime ingestion / turn lifecycle guard logic.

1. a resumed thread preserves a stale activeTurnId
2. the thread can end up in an invalid state like ready + activeTurnId != null
3. after that, later turn.started / turn.completed events for the real current turn are treated as conflicting with the stale active turn and ignored
4. the composer never receives the transition it uses to clear local send-pending state, so the spinner and frozen timer persist

Suggested fix

• only preserve activeTurnId across resume / session-start / thread-start lifecycle events if the thread is actually still running a turn
• if the current session is not running, clear activeTurnId
• ideally also clear activeTurnId if the referenced turn is already completed/settled in the projected turn state
• keep the strict guard for genuinely unrelated stale turn.started events; the problem seems to be that the stale active turn is being preserved too aggressively

Suggested regression test

A test like this seems like it would catch the bug:

1. seed a thread with session status ready and a stale non-null activeTurnId
2. emit session.started or thread.started
3. emit a new turn.started for a different turn id
4. verify the new turn is accepted and becomes the active running turn
5. emit turn.completed
6. verify the session becomes ready and activeTurnId is cleared

[zgriffiin]

I was trying to resolve this issue in a fork of 0.15 and the agent investigating it reported this, if it helps. I have not seen the issue since patching it with the changes below (3 hours so far).

Findings

This is not just a Windows-only UI glitch. I found a real server-side lifecycle bug: Codex turn.aborted events were recognized by the adapter, but they were not treated as terminal by the session manager or runtime ingestion. That could leave the thread stuck in running, keep the UI showing work in progress, block follow-up interaction, and retain buffered per-turn state longer than it should. The concrete fixes are in [codexAppServerManager.ts] and [ProviderRuntimeIngestion.ts]

I patched the aborted-turn path so it now clears the active turn immediately, settles the orchestration session as interrupted, and flushes buffered assistant output instead of leaving that turn hanging in memory. The interrupted-output cleanup is in [ProviderRuntimeIngestion.ts]