Repository navigation
Claude session closed right after a background job ends, so the wake turn never runs #33041
Description
Before submitting
- I searched existing issues and did not find a duplicate. ([Bug]: Usage-limited Claude thread is never armed for auto-resume when background-task wake runs finish as
completedright after the limit stop #16815 is related, but covers usage-limit wake arming.) - I included enough detail to reproduce or investigate the problem.
Area
apps/server, Claude provider session lifecycle (orchestration-v2)
Steps to reproduce
- In a Claude thread, start one background Bash command that runs for a few minutes.
- Optionally call
t3_background_waitfor it, then let the turn end. The thread is now idle with that job as the only background task. - Wait for the job to end.
I have not reduced this to a minimal repro. It happens often in long sessions, not on every completion.
Expected behavior
The task_notification for the completed job starts a wake turn in the thread.
Actual behavior
T3 sends query.close immediately after the background list empties, and the wake turn never starts. The thread stays idle until the next user message. On resume, Claude reports the job as stopped with "Background shell command didn't finish before the previous session ended", although it finished successfully.
Provider event log (events.<thread>.log, UTC, shortened):
16:40:17.894 incoming result success (stop_reason end_turn)
16:48:16.389 incoming system task_updated patch.status=completed
16:48:16.390 incoming system task_notification status=completed "... completed (exit code 0)"
16:48:16.392 incoming system background_tasks_changed tasks=[]
16:48:16.522 outgoing query.close
18:04:20.697 outgoing query.open (resume) after the user's next prompt
18:04:20.711 incoming system task_notification status=stopped "didn't finish before the previous session ended"
The session had only been idle for 8 minutes, so DEFAULT_IDLE_TIMEOUT_MS (30 min) does not obviously explain the close. I could not identify the code path that triggers it.
Across my 46 provider logs: 28 completed task_notification events arriving while idle were followed by query.close within 2 seconds, and 27 of 72 query.close events came within 2 seconds of an empty background_tasks_changed.
The comment in ClaudeAdapterV2.ts already notes that an empty background_tasks_changed can precede task_notification, so a close decided at that moment looks like the race.
Impact
Unattended work stops silently: in this case a staged production rollout waited 76 minutes for a message nobody was going to send. The Claude prompt cache also expires during the stall, so the resumed session pays for a full cache rewrite.
Version or commit
T3 Code 0.1.7 (AppImage), Claude Code 2.1.319
Environment
Linux, desktop app, Claude provider via Agent SDK, permission mode bypassPermissions
Logs or stack traces
See "Actual behavior".
Workaround
Keep a second background job (for example a long sleep) running so the list is not empty when the job ends, and use schedule_task as a fallback wake. I am testing the first; I have not confirmed it yet.
Activity
juliusmarminge commentedon Nov 12, 2026
I tried to reproduce this on the current build and could not.
On origin/main ddc4f57 I ran an isolated dev server (T3CODE_DEV_SEED=0 vp run dev), added a scratch git project with the t3 CLI, and started a Claude Haiku thread with
thread start --provider claudeAgent. I asked the agent to runsleep 40; echo finishedas a background Bash command, end its turn, and reply WAKE-OK when the completion woke it. The turn ended at 06:18:03 (result success). At 06:18:41.855-.857 the provider log matches the reporter's: task_updated completed, task_notification completed, then background_tasks_changed tasks=[]. After that it differs: 120 ms later Claude sent its own wake turn (system init, then an assistant message 'WAKE-OK' and result success), and T3 sent no query.close. I tried this once. The reporter says the bug is intermittent (28 of their idle completions), so a single clean run does not rule it out. I did not find what calls a release or restart in that window.Closing as not planned. If it still happens for you, reply with the exact steps and the version you are on and it will be looked at again.
ZentZo86 commentedon Nov 14, 2026
Note
🤖 Claude Opus 5.5 responding on behalf of ZentZo86
Still happening on T3 Code v0.1.9 (macOS desktop, Claude Agent SDK on Claude Code 2.1.322, model
claude-opus-5-5). Same event sequence as the original report: T3 sentquery.close12 ms after the background list emptied, and the wake turn never ran.Steps (what the thread did)
run_in_background, about 8 minutes) and calledt3_background_waitfor it.result success,stop_reason end_turn). The thread was idle, and that command was its only background task.Provider event log (
events.<thread>.log, UTC 2026-11-13, fields shortened)What happened next
No response requested.from model<synthetic>with 0 tokens. The model later read it as its own reply.How often (from a scan of our provider logs; these counts are ours, not a controlled repro)
Because it only shows up in a small share of completions, one clean run will often miss it. Could this be reopened? I can pull more fields from this log if they would help.