Background tasks killed by bridge stopTask while session open in phone app (no user action)

Summary

Long-running background Bash tasks in a Claude Code CLI session are being killed by the
harness's internal stop-task routine without the user requesting it, while the same session is
open in the claude.ai phone app. The user was passively viewing the session on mobile; no
stop control was knowingly tapped.

Environment

• Claude Code CLI v2.1.220, Linux x86_64 (Ubuntu, kernel 6.8), session running in tmux
• Session bridged to claude.ai (visible in web + iOS/Android phone app)
• Background tasks: Bash tool with run_in_background: true, each wrapping a long

(30 min – 3 h) external CLI process (timeout ... codex exec ...)

What happened

Four consecutive background tasks were killed minutes into (or hours into) their runs, each
reported to the model as <status>killed</status> / Background command "…" was stopped.
Timeline (local, +0200): launched 12:10 → killed 12:46:30; launched 12:47 → killed 12:49;
launched 13:21 → killed 13:24:33; launched 13:50 → killed 13:53:24. Roughly a dozen identical
tasks earlier the same day completed normally.

Investigation performed (host-side)

• The killed / "was stopped" status template is produced only by the harness's own task-kill

path (SIGTERM to the task shell, delayed SIGKILL to its process group). Externally-signalled
tasks report "failed with exit code N" instead (verified against a control case in the same
session's history: pkill-terminated tasks showed "failed with exit code 144").

• One killed task's child process (different process group) **survived orphaned and completed its

work 10 minutes after the harness reported the task killed** — consistent with the harness
group-kill, inconsistent with any pattern-based external pkill.

• All host-local killers ruled out: no OOM (kernel logs clean, >100 GB free), no cron, no relevant

systemd user/system timers, systemd-oomd inactive, no settings.json hooks, no TaskStop tool
calls in any session transcript, all other Claude sessions idle for days.

• The CLI bundle exposes a stopTask method on the remote/bridge RPC roster (alongside

getSettings, generateSessionTitle, messageRated, …). All four kills landed during idle periods
(1.7–36 min after a turn ended), several shortly after turns the user had just been viewing on
the phone app. Kills stopped entirely once the session stayed continuously active locally.

Conclusion / suspicion

Bridge-originated stopTask requests from a mobile/web client with the session open — either a
stray/misregistered tap on a stop affordance or a client-side bug (e.g. stop dispatched on some UI
interaction or reconnect). The user denies intentionally stopping anything, and four occurrences
in ~70 minutes with none before or after that window points at a client behavior rather than
deliberate action.

Impact

Multi-hour orchestrated work (subagent pipelines driving external CLIs) is repeatedly destroyed
mid-run; the model has no way to distinguish a user-intended stop from these, and the transcript
records no reason for the kill.

Asks

1. Log/attribute task stops: when a background task is stopped via the bridge, record the origin

(client type/surface) in the session transcript so agents and users can see why a task died.

1. Audit mobile-app stop affordances for accidental/erroneous stopTask dispatch while viewing a

session with running background tasks.

1. Consider a confirmation for stopping long-running background tasks from remote clients.