[Bug]: ⚠️ Claude provider: every turn gets stuck showing "Working..." forever after the CLI already completed — stop button doesn't recover it

[nikolas-nelson]

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

Reproduction

1. Corporate network with an HTTPS proxy in front of all outbound traffic (relevant — this manifests very consistently in this kind of environment, may not repro on unrestricted networks).
2. Open T3 Code, start a brand-new thread, model = Claude (Bedrock), send any message (e.g. "hi").
3. The assistant response renders correctly.
4. The "Working for Xs" indicator never clears. Clicking Stop repeatedly does nothing.
5. Confirmed via local state.sqlite: projection_thread_sessions.status stays running with a stale active_turn_id even though the provider log shows claude/result/success / terminal_reason:completed for that turn.

Expected behavior

After the Claude provider CLI reports a completed turn (claude/result/success, terminal_reason: completed),
the thread session should transition back to ready and accept new messages/turns.

Actual behavior:
The CLI subprocess completes and streams the correct assistant response, but T3 never emits a turn.completed
domain event for it. The thread session stays status: running with a stale active_turn_id forever. The UI
shows "Working for Xs" indefinitely, the composer stays locked, and clicking Stop only records an interrupt
request — it does not recover the session. This happens on ~100% of turns in my environment (reproduces even on
a one-word "hi" with no tools involved). Confirmed via the local state.sqlite (projection_thread_sessions
never gets a status:"ready" follow-up event) and per-thread provider logs
(~/.t3/userdata/logs/provider/<threadId>.log), which show the CLI reporting success while T3's server-side
event log shows nothing after thread.activity-appended.

Likely cause (from apps/server/dist/bin.mjs in app.asar): ClaudeAdapter's completeTurn() awaits
context.query.getContextUsage() (from @anthropic-ai/claude-agent-sdk) before emitting turn.completed.
That SDK call has no timeout on its underlying control-request Promise. In my environment (corporate network,
all traffic through an internal HTTPS proxy, Claude via AWS Bedrock) this call appears to hang, which blocks
turn.completed from ever being emitted — even though the CLI already finished and streamed its answer.

Actual behavior

Environment

• T3 Code (Nightly) 0.0.29-nightly.20260724.892
• macOS (Intel), corporate network with an internal HTTPS proxy in front of all outbound traffic (AWS Bedrock via corporate proxy, not direct Anthropic API)
• Provider: Claude Agent (claudeAgent adapter), models eu.anthropic.claude-sonnet-5 / eu.anthropic.claude-opus-4-8 via AWS Bedrock
• claude CLI 2.1.218, invoked by T3 with --setting-sources=user,project,local

Summary

Every single turn, even a trivial one-word prompt like "hi", gets stuck showing "Working for Xm Ys" indefinitely in the UI. Clicking Stop does not recover it — it only records a thread.turn-interrupt-requested domain event but the session never actually returns to ready. This happens on every new thread/session, 100% reproducible, not an occasional race.

Root cause (confirmed from logs + DB + app.asar source)

1. The claude CLI subprocess spawned by T3 does complete successfully. The per-thread provider log (~/.t3/userdata/logs/provider/<threadId>.log) always shows a clean:

   claude/result/success ... "terminal_reason":"completed" ... "result":"Ahoj! 👋\n\nJak ti můžu dnes pomoct?"
   

2. T3's server never turns this into a turn.completed domain event. Querying the local event store confirms it:

   -- ~/.t3/userdata/state.sqlite
   SELECT event_type FROM orchestration_events WHERE stream_id='<threadId>' ORDER BY sequence;
   -- thread.created, thread.message-sent, thread.turn-start-requested,
   -- thread.session-set (status:starting), thread.session-set (status:running),
   -- thread.message-sent (assistant text), thread.activity-appended
   -- ... and then NOTHING. No thread.session-set with status:"ready" ever follows.

3. projection_thread_sessions for the thread stays status='running' with active_turn_id pointing at the turn that the CLI already finished, forever (until the idle reaper eventually kills it ~30 min later, or the user restarts the app — which does not fix it either, since it's persisted in state.sqlite).
4. Clicking Stop repeatedly only emits thread.turn-interrupt-requested (confirmed via orchestration.command.thread.turn.interrupt spans in server.trace.ndjson) — it never flips the session back to ready on a turn the provider has already completed and exited.

Where it appears to break (apps/server/dist/bin.mjs, extracted from app.asar)

In the Claude adapter's completeTurn() (called from handleResultMessage when a result SDK message with subtype:"success" arrives):

const completeTurn = Effect.fn("completeTurn")(function* (context, status, errorMessage, result) {
 ...
 const contextUsageSnapshot = yield* queryCurrentContextUsage(context, ...);
 ...
 yield* offerRuntimeEvent({ type: "turn.completed", ... }); // <-- never reached
 ...
});

const queryCurrentContextUsage = Effect.fn("queryCurrentContextUsage")(function* (context, totalProcessedTokens) {
 if (!context.query.getContextUsage) return;
 const usage = yield* Effect.promise(async () => {
 try {
 return await context.query.getContextUsage?.();
 } catch {
 return;
 }
 });
 ...
});

context.query.getContextUsage() comes from @anthropic-ai/claude-agent-sdk's Query.getContextUsage():

async getContextUsage(){return(await this.request({subtype:"get_context_usage"})).response}

which goes through the SDK's internal request() control-protocol call:

request(e){
 let t = Math.random().toString(36).substring(2,15);
 ...
 return new Promise((o,i)=>{
 this.pendingControlResponses.set(t, { handler: ..., reject: i });
 Promise.resolve(this.transport.write(...)).catch((s)=>{ this.pendingControlResponses.delete(t); i(s) });
 });
}

This Promise has no timeout. If the CLI subprocess never sends back a control_response for the get_context_usage control request (e.g. because it's blocked on an internal network call under a corporate proxy, or any other stall), the await in queryCurrentContextUsage hangs forever. Since completeTurn() awaits this before emitting turn.completed, the whole turn-completion pipeline silently deadlocks even though the CLI already streamed the final result message and the user-visible answer.

This would explain why:

• The visible chat response ("Hi! 👋 ....") does show up (it comes from the earlier assistant message handling, before completeTurn runs).
• The turn never settles to ready, so the UI shows "Working..." forever.
• Stop does nothing useful — interrupting a turn whose SDK query object is itself hung on an unrelated internal request doesn't unstick that hung await.
• This reproduces on literally every message ("hi" included), not just tool-heavy turns — consistent with a stall in a fixed post-turn step (getContextUsage) that runs on every single turn completion, not with something related to turn content.

I don't have 100% certainty this exact control request is what's hanging (I was not able to attach a debugger to the running claude CLI process to confirm), but the DB/log evidence rules out everything before completeTurn(), and the code path is the only awaited, unbounded, non-timed-out promise between "CLI reports success" and "turn.completed is emitted."

Suggested fix

• Add a timeout (e.g. 5–10s) around context.query.getContextUsage() in queryCurrentContextUsage (apps/server ClaudeAdapter), falling back to the last known usage snapshot on timeout — the existing try/catch only handles rejections, not hangs.
• More generally, any await on an SDK control-request Promise inside completeTurn() should be wrapped in a race against a timeout, since a stuck one currently blocks the entire terminal lifecycle event for that turn.

Impact

Blocks work completely

Version or commit

T3 Code (Nightly) 0.0.29-nightly.20260724.892

Environment

No response

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

Manually patching the local DB (~/.t3/userdata/state.sqlite, table projection_thread_sessions) — setting status='ready', active_turn_id=NULL for the affected thread — unsticks that specific thread, but the same thing recurs on the very next new session, since the root cause is a per-turn stall, not corrupted state.

[SvejoDev]

+1

[dpatou]

Hitting this without the network angle: no proxy, direct Anthropic API (HTTP(S)_PROXY, ANTHROPIC_BASE_URL, CLAUDE_CODE_USE_BEDROCK/_VERTEX all unset), Arch Linux, nightly 0.0.29-nightly.20260727.915, claudeAgent + claude-opus-5, CLI 2.1.220.

Not 100% of turns here. queryCurrentContextUsage spans from one session: 409 ms, 8.3 s, 262 s. Unbounded latency rather than a deterministic hang.

The 262 s one never resolved on its own — 11:35:40 + 262.207 s = 11:40:02.2, matching provider.stopAll at 09:40:02.258Z. Shutdown killed the CLI, the promise rejected into the existing catch, which is why the span exits Success.

The part that matters more: it freezes every thread on the server, not just the stuck one. Two threads created during the window had turn-start-requested accepted and never started — no provider/<threadId>.log, no CLI spawned. One was codex, in a different project:

1754 750668bd turn-start-requested {"instanceId":"claudeAgent_vanilla","model":"claude-opus-5"}
1758 8d9f306d turn-start-requested {"instanceId":"codex","model":"gpt-5.6-sol"}

ProviderCommandReactor processes everything on one sequential fiber: single makeDrainableWorker (ProviderCommandReactor.ts:1085), and DrainableWorker.ts:50 is TxQueue.take + Effect.forever with no concurrency. Both turn-start-requested and turn-interrupt-requested queue behind the hung call — which is also why Stop does nothing, it never gets dispatched.

On the fix: Effect.timeout alone won't do it, Effect.promise is uninterruptible. Needs Effect.disconnect:

.pipe(Effect.timeout("10 seconds"), Effect.disconnect, Effect.orElseSucceed(() => undefined))

Separately worth containing: any unbounded await in any adapter reproduces the same server-wide freeze.

[karimou5]

Same failure mode on Linux with no proxy and no Bedrock/Vertex, and I have a
dataset that pins the delay to an exact value rather than "hangs forever".

Environment

• Linux x64, T3 Code nightly channel, builds spanning 0.0.32 → 0.0.34
  (AppImage; some of them rebuilt locally from the nightly source tree with
  unrelated screenshot/image patches only).
• Provider: claudeAgent, claude CLI 2.1.231 → 2.1.233.
• Direct Anthropic API. HTTP_PROXY, HTTPS_PROXY, ANTHROPIC_BASE_URL,
  CLAUDE_CODE_USE_BEDROCK, CLAUDE_CODE_USE_VERTEX all unset, no
  apiKeyHelper, no custom base URL.

The delay is a hard 601s, not unbounded

Parsed every claude/result/success → turn.completed pair across all
per-thread provider logs (~/.t3/userdata/logs/provider/*.log*): 55 turns
total, 20 of them blocked.

The distribution is strictly bimodal: either 0-3s, or 601s. Nothing in
between.

day	turns	median	max	blocked >60s
Aug 10	13	0.0s	601.6s	3
Aug 13	2	601.5s	601.5s	2
Aug 14	5	601.0s	602.3s	3
Aug 15	22	0.8s	602.3s	8
Aug 16	12	2.7s	608.8s	4

Blocked values, verbatim: 601.0, 601.1, 601.2, 601.2, 601.3, 601.3, 601.4,
601.4, 601.4, 601.5, 601.5, 601.5, 601.6, 601.6, 602.3, 602.3, 608.8, 194.3.

That clustering suggests a 600s timeout somewhere on the control path rather
than a promise that never settles. In this environment the turn does eventually
complete, but the composer is locked and the thread reads "Working" for the full
ten minutes.

Confirmation that getContextUsage is what gates it

Cleanest single case, one provider log:

15:33:16.818 claude/result/success <- CLI finished, answer already streamed
15:43:25.653 thread.token-usage.updated <- +608.8s
15:43:25.653 turn.completed <- same millisecond

Across all 20 blocked turns, the first event to arrive after the stall is:

14x thread.token-usage.updated
 4x claude/system/background_tasks_changed
 4x claude/system/init
 3x claude/assistant
 3x claude/system/commands_changed

thread.token-usage.updated landing in the same millisecond as
turn.completed in the majority of cases is consistent with the reported root
cause: completeTurn() awaits the context-usage control request before emitting
turn.completed.

It stalls unrelated threads too (confirms the earlier comment)

One window with several concurrent threads (one codex, four claudeAgent),
largest gap between consecutive orchestration_events per stream over ~4h:

thread	provider	events	largest gap	mean gap
A	codex	1786	(long turn)	8.4s
B	claudeAgent	408	609s	6.5s
C	claudeAgent	87	602s	13.5s
D	claudeAgent	657	1342s	5.5s
E	claudeAgent	5	1033s	206.6s

So the stall is not confined to the thread whose turn is blocked.

Possibly relevant load on the control channel

The same CLI control channel also carries claude/system/commands_changed
payloads of ~150 KB (~390 entries) in this setup, plus
background_tasks_changed. Two of the five distinct unblock events are exactly
those, so a busy control channel may be what pushes the context-usage request
into its timeout.

Happy to run any read-only query or share more aggregate log parsing if useful.

[t3dotgg]

Thanks for the detailed report and the follow-up timing data. We believe this is fixed by PR #5891 and PR #7719.

The first PR adds a one-second timeout around the getContextUsage request, so a stalled request can no longer block turn completion. The second PR repairs orphaned running sessions during startup, including the stale state that remained after a restart.

I'm closing this as fixed as part of an automated pass on all open issues. If this still happens in a build that includes both PRs, please reply with the T3 Code version and the timing between claude/result/success and turn.completed, and we can reopen it.