Background tasks: dead agents/shells render as Running; lost shell-completion wake-ups freeze agents; app lifecycle events recorded as 'interrupted by user'

Resolved 💬 2 comments Opened Jun 13, 2026 by arielserbin Closed Jun 16, 2026

Environment

  • Claude Code desktop app (macOS, Darwin 25.5.0), app entrypoint claude-desktop, version 2.1.170
  • Model: claude-fable-5
  • Workload: a long orchestration session in a private project — parent session spawning background agents (Agent tool, run_in_background: true, worktree isolation), agents in turn spawning background shells (Bash, run_in_background: true)
  • Session ID, in case it helps internal telemetry lookup: 7a86dff8-4d01-49e2-a956-71c308e527eb

Three related defects observed in one session, all around background-task lifecycle. Timestamps below are UTC from the subagent transcript JSONL files (2026-06-12/13).

1. Dead background tasks keep rendering as "Running" with live-ticking timers

Agents whose transcripts end with [interrupted by user] at 18:51:17.233Z / 18:51:17.237Z (two agents, same instant) and 21:44:41.566Z remained in the Background tasks panel as Running for the next ~5–7 hours, with wall-clock timers still accumulating (e.g. "6h 52m" for an agent that had been dead for 5 of those hours) and token/tool counters frozen at time-of-death values.

The backend registry agreed they were gone: TaskStop on those task IDs returned No task found with ID: … — while the panel still showed them Running. The panel and the task registry are evidently not reconciled.

Consequence: with relaunched replacement agents running under the same display names, the panel showed duplicate ghost/live pairs and the user had to be told "kill the older of each pair by its timer" — easy to get wrong, and they understandably read the whole panel as untrustworthy.

2. Background-shell completion wake-ups can be lost → parent agent freezes forever mid-wait

Two background agents each spawned a backgrounded CI-watch shell (gh run watch-style, bounded). The shells exited normally when CI completed (~00:41Z; ps confirmed no surviving processes). But the "your background shell finished" wake-up apparently never reached either agent: both agents' transcripts halt at 00:34:38.237Z / 00:34:38.244Z mid-wait and never append again. The panel showed both the frozen agents and their already-exited shells as Running for 75+ further minutes, timers ticking.

All work those agents had already committed/merged was unaffected — they just never woke to perform their final verification/reporting step, and nothing surfaced to the parent session to say so. The parent only discovered the freeze by stat-ing transcript files directly.

3. Mass "interrupted by user" with no user interaction, millisecond-identical across agents

Two separate incidents where multiple independent background agents were terminated in the same instant with near-identical timestamps (18:51:17.233Z/.237Z; and the 00:34:38.24Z simultaneous freeze above has the same signature). No human pressed Stop at those times. The pattern suggests an app lifecycle event (auto-update/restart, sleep, or similar) is being recorded as a user interrupt for all in-flight subagents at once — and no notification of these terminations is delivered to the parent session (no task-notification fires; the parent learns only by inspecting transcript files).

Suggested fixes

  • Reconcile the Background tasks panel with the task registry (a row whose task the registry no longer knows should not render as Running; show terminal state + stop the timer).
  • Make background-shell completion delivery robust across whatever event caused the freeze window (or have agents poll for shell state as a fallback).
  • When an app lifecycle event terminates subagents, label it as such (not "interrupted by user") and emit task-notifications to the parent session so orchestration logic can react (the parent in this session has a relaunch-on-kill policy that silently failed because no notification arrived).

Repro sketch

  1. Spawn 2+ background agents; have each background a long-ish shell and wait on it.
  2. While they wait, trigger an app restart/update (or let the machine sleep).
  3. Observe: agents die with [interrupted by user] (or freeze mid-wait), panel keeps showing everything Running, parent session receives no notifications, TaskStop says the tasks don't exist.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗