[Bug]: A thread waiting on background work stays stranded after a backend restart until the user sends a message #15358

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

Summary

A Claude agent can end its turn waiting on a background task (run_in_background) and rely on the completion notification to wake it. If the backend dies in the meantime, the task dies with the agent process. Recovery records exactly what was lost, but the thread stays idle and looks finished. The agent only learns about it when the user next sends a message. In our case a triage thread sat like that for 27 minutes until I noticed it was stuck.

Visual explainer with the full timeline: https://post.patchyhq.com/d/078j555zejie

Steps to reproduce

1. In a Claude thread, ask the agent to start until [ -e /tmp/release-b ]; do sleep 1; done with run_in_background: true, then end its turn and wait for the notification.
2. Once the turn has ended, kill -9 the backend from a terminal outside T3 (its pid is in ~/.t3/userdata/server-runtime.json). Let the desktop restart it.
3. touch /tmp/release-b and wait.

"Continue threads after restarts" is at its default (off).

Expected behavior

The thread is woken with the cancellation note, or at least shows that its background work was lost.

Actual behavior

The run stays completed and the thread stays idle indefinitely. Recovery stored the loss correctly on the run straight away:

restartCancelledBackgroundWork: [{"kind":"shell","label":"Wait for release-b then record time (id b6w74smo0)","id":"b6w74smo0"}]

Nothing woke the thread. In the original incident, the note reached the agent only when I nudged it 27 minutes later:

Note: the T3 server restarted, and this background work was cancelled before it finished. It will not report back: - shell: Wait for codex trace to finish (id btuwr7ruo)

Cause

• RestartBackgroundNote.ts:87 builds the note, and ProviderTurnStartService.ts:1127 prepends it to the next user input.
• The automatic path exists (ProviderRuntimeRecoveryService.ts:635 → RestartContinuation.ts:120), but it is gated on continueThreadsAfterServerUpdate, which defaults to false (packages/contracts/src/settings.ts:1206).

An agent that ended its turn waiting on a task has handed control to that task's notification. Waiting for the user is always wrong in that case, whatever the setting.

The same blind spot affects orchestration. t3_thread_wait returns once the latest run is terminal (ThreadManagementService.ts:610), and t3_thread_read doesn't expose pendingBackgroundTasks (orchestrationV2.ts:831). Our orchestrating thread got completed for this child while it was still waiting on its codex job, and had no way to see that the child had been stranded.

Possible fix

• When recovery cancels a thread's background tasks, always continue that thread with the note, whatever the setting. If that's too aggressive, show a "background work lost" state in the sidebar.
• Return pendingBackgroundTasks and restartCancelledBackgroundWork from t3_thread_read and t3_thread_wait, so orchestrators can tell "done" from "waiting" and "stranded".

Related

• PR fix(server): restarts keep delegated tasks, queued threads, and stops intact #15323 makes restart continuation keep delegated tasks and carry this note, but only with "Continue threads after restarts" on. With it off, this repro behaves the same.
• [Bug]: A Claude thread waiting on a background command sends a false "Thread completed" alert #15099: background Bash counts as done, so a waiting thread sends a false "Thread completed" alert. It's the same blind spot as the t3_thread_wait point.
• [Bug]: Idle-session reaper kills a session whose sub-agent is still running a background job #15235: the idle-session reaper kills a sub-agent's background job, and nobody is told.
• [Feature]: Pause, update, and resume active threads as one operation #15186: feature request for one operation to pause, update and resume active threads.

Impact

Major degradation or frequent failure

Version or commit

0.0.46-nightly.20261003.2632 (f391794), Orchestrator V2

Environment

Linux 7.2.5 (Arch-based), desktop AppImage, Claude Code 2.1.288 via Agent SDK 0.3.276, Claude Opus 5.5

Workaround

Turn on Settings → General → "Continue threads after restarts", or send any message to threads that were waiting when the backend restarted.

Related reports from the same incident: #15357 (agents that were mid-turn survive the crash and keep working, unseen), #15359 (a killed backend is logged as "Failed to read the exit status").

Filed by Allison Mahmood. Investigated and drafted with Claude Opus 5.5 in Claude Code.