Skip to content
Source
Sign inSign up

[Bug]: t3 thread start --wait returns when the turn ends, while t3_background_wait still keeps the thread working #34688

Send to my agent
Closedmallocator(GitHub profile, opens in a new tab) opened this issue 0 comments

Before submitting

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

Area

apps/server

Steps to reproduce

  1. Run t3 thread start . "Run sleep 300 in the background (run_in_background), call t3_background_wait on its task ID, and end your turn. When it finishes, reply DONE." --provider claudeAgent --model claude-opus-5-5 --wait.
  2. The agent starts the command, calls t3_background_wait and ends its turn. The sidebar shows the thread under Working with a "Waiting" pill.
  3. t3 thread start --wait exits 0 at that moment and prints the agent's interim message.

Possible fix

  • waitForRun passes untilDelegatedWorkSettled: true and reports resultRun (its reply, status and exit code) instead of the first run.
  • The 15 s check of pendingRequestCount keeps working, so a question asked in a wake run still exits 2.
  • The --wait help text says it also waits for background work the agent waits on.
  • #34668 / #34674: t3_thread_list now reports these threads as waiting. The CLI's --wait still returns early.
  • #24297, #28114, #32563: the same gap for delegate_task, where the task finishes before the child's background-wake run.

Expected behavior

--wait waits until the thread has nothing left to do: the awaited background work has ended, and the run it wakes has finished. It prints that run's reply and takes its exit code from that run. This is what t3_thread_wait already does with untilDelegatedWorkSettled: true, which returns resultRun, the run with the final answer. t3 thread send --wait should behave the same way.

Actual behavior

--wait returns when the first turn ends. It exits 0 and prints the message the agent wrote before it paused, for example, "Waiting for the smoke suite to finish." The real work and the final answer arrive in a later run, after the command has returned.

A script that treats exit 0 as "finished" acts too early. In our case, LoTaR runs agent jobs as t3 thread start … --wait. It marked the job completed and closed the ticket while the agent was still running the test suite. The test results and the agent's report came after the ticket was closed.

Cause: waitForRun in apps/server/src/cli/thread.ts calls t3_thread_wait with { threadId, runId, timeoutMs } only. It never passes untilDelegatedWorkSettled, so the wait ends with the run that called t3_background_wait. The server side already supports the longer wait.

Impact

Major degradation or frequent failure

Version or commit

v0.1.9

Environment

T3 Code desktop app on macOS, t3 CLI from ~/.t3/bin/t3. Provider: Claude (claude-opus-5-5), runtime mode: auto.

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

None from outside the thread in v0.1.9: t3 thread show --json and t3 thread list --json report the thread as finished while it waits on background work. We now tell agents in their prompt to run checks in the foreground and finish before their last message.

  1. mallocator(GitHub profile, opens in a new tab) added labelsneeds-triage

  2. juliusmarminge closed this

Sign in to join this conversation.