Before submitting#
Area#
apps/server
Steps to reproduce#
- 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.
- The agent starts the command, calls
t3_background_wait and ends its turn. The sidebar shows the thread under Working with a "Waiting" pill.
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.
Related#
- #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.