[Bug]: An awaited background task is lost with no wake or note when a Claude provider process exits while the thread is idle #30156

Area

apps/server

Steps to reproduce

Self-hosted T3 server (Linux, systemd user service), web client, Claude provider.

1. Control: in a new Claude thread, ask the agent to run sleep 30 with run_in_background and end its turn. It is woken when the command exits. This works.
2. In the same thread, ask the agent to run sleep 180 with run_in_background, call t3_background_wait on that task, and end its turn.
3. After the turn ends, send SIGTERM to that thread's claude process only. Leave the T3 server running. The background sleep dies with the process.
4. Wait past the 180 seconds.
5. Send any message to the thread.

Expected behavior

When the provider process exits while the thread is waiting on background work, the agent is woken with a short note saying which background tasks were lost, as the server-restart path does ("T3 Code restarted and stopped background work"). It can then re-arm them.

Actual behavior

No wake and no note. At the moment of the kill T3 records the provider thread as idle with an empty pending-task list, and the session still shows ready. Nothing happens until the next user message (step 5). That message starts a new Claude process, which then reports: "Background shell command didn't finish before the previous session ended".

In normal use this looks like an agent that says "I'll report back when CI finishes" and never does. We've hit it several times with agents waiting on CI, a merge or a long test. The agent only noticed the lost watcher after the user poked the thread. In those real cases we can't tell whether the server restarted or only the provider process died. The repro above isolates the provider-death path.

From reading the source (commit 30654b3), the cause looks like this: when a Claude query process exits and no turn is active, finalizeActiveTurnAfterQueryExit in ClaudeAdapterV2.ts calls resetBackgroundTaskStateForNativeThreadProcess. That clears the pending background tasks and emits an idle provider thread. Nothing records the awaited tasks as cancelled work, and nothing queues a continuation. The startup recovery that handles server restarts never runs here, because the server didn't restart.

Impact

Major degradation or frequent failure

Version or commit

reproduced on 0.1.7-nightly.20261102.4066. Current install is 0.1.7-nightly.20261103.4119 (from t3 --version), not re-tested yet.

Environment

Ubuntu Linux (kernel 6.8), Node 24.19, Claude Code 2.1.317 via the Claude Agent SDK, model claude-sonnet-5-5. Self-hosted server, web client. Codex not tested.

Logs or stack traces

# Timeline from the repro (UTC)
13:35:15  control: background `sleep 30` wakes the agent with no user message
13:35:36  test: `sleep 180` started in background, t3_background_wait called, turn ends
13:35:50  SIGTERM to the thread's claude process; server PID and uptime unchanged
          provider thread -> status idle, pending background tasks []
13:40:40  no wake, no note (2m10s after the job would have finished)
13:40:59  user message -> new claude process -> task_notification:
          "Background shell command didn't finish before the previous session ended"

Workaround

Send any message to the thread after a provider process dies. For work that must finish, have the agent use a bounded foreground wait instead of a background one.

Suggested fix

1. In the query-exit path with no active turn, check whether the roster being cleared held awaited tasks before clearing it. If it did, record them as cancelled background work on the thread's last run and queue the same continuation that server-restart recovery uses. The agent then wakes with "N background tasks were lost when the provider process exited: …" and can re-arm them.
2. Longer term, persist registered background waits outside the provider process so a restarted process, or the server, can re-check or re-arm them.

Related

#28208, the same symptom after a server restart (fixes in #28994 and #28500). This report is the provider-process-exit path with the server still up, which that recovery doesn't cover. Also #29319 (subagents killed when the Claude process ends) and #29772 (t3_background_wait succeeding on missing task IDs).