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

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.