Background Bash tasks are internally stopped during Remote Control bridge re-registration under intermittent createCodeSession 401s (v2.1.212, Linux)

Summary

On Linux with Claude Code v2.1.212, a long-lived Remote-Control-enabled session experiencing repeated intermittent 401 Authentication failed responses from POST /v1/code/sessions had four in-flight run_in_background Bash tasks asynchronously stopped by Claude Code — uncommanded and causally opaque from the session's perspective. Each task notification reported <status>killed</status> / "was stopped", matching harness-internal cancellation semantics and differing from the failed + exit-code result produced by a controlled external SIGKILL on the same host and build. No TaskStop tool calls, no RC slash-commands, no context compaction, and no OS-level killer (user, kernel, and system journals clean of oom/oomd/cgroup events in both incident windows) were involved. All four cancellations occurred during RC bridge-session re-registration activity (the session logged ~80 such entries that day under the flap); a healthy engaged-RC session and a nine-hour same-version control session with RC registered but never engaged ran comparable background tasks with zero cancellations. Working hypothesis, explicitly ranked not proven: a specific RC failure/recovery, bridge-replacement, or session-reset path shares or invokes background-task cleanup. Ordinary bridge-session events are not sufficient — several occurred without task loss, and one task survived across multiple events and completed normally.

Environment

• Claude Code v2.1.212, Linux 6.17.0-40-generic (x86_64, native, not WSL)
• Session: long-lived interactive tmux session, vim-mode, model Claude Fable (included for reproducibility, not asserted causal)
• RC: enabled and engaged; the RC create endpoint was intermittently returning 401 on valid OAuth tokens all day (server-side per-request non-determinism, ~80% 401 / ~20% 200 on byte-identical requests, confirmed via fresh-connection curl on both of our Max accounts that day — request IDs available)
• Auth: claude.ai OAuth (Max), correctly scoped token
• Incident timestamps (UTC): task cancellations at 2026-07-17T22:28:43Z, 22:29:29Z, 2026-07-18T02:24:28Z, 02:25:58Z (session id 4711ad79-…, bridge session cse_01UNUV…)
• No proxy was present during the incidents (a mitmproxy harness exists for the offered reproduction protocol only)

What we observed (evidence chain)

1. Harness-internal cancellation signature. All four notifications: <status>killed</status> / Background command "…" was stopped. Discriminator run on the same host/build: an externally SIGKILLed background task instead reports <status>failed</status> / "failed with exit code N". The signature establishes that Claude Code initiated or classified the termination as an internal cancellation — it does not by itself identify the internal caller.
2. No commanding input. Transcript shows no TaskStop, no /rc or other local commands, no compaction events at or near the kill times; the session's operator observed the kills with surprise and logged them as an anomaly in real time.
3. No external killer. User journal, kernel journal (journalctl -k), and system journal are clean of oom/oomd/cgroup-kill entries in both incident windows; the only host reaper (a tmux-session reaper) only touches explicitly tagged sessions and logged nothing.
4. Temporal association with bridge re-registration. Each cancellation falls in the same transcript-append window as a bridge-session re-registration entry (timestamps on those entries are append-order bounds, not exact causal instants — stated as such). Kills came in two bursts (46s and 90s re-arm-to-kill intervals) during flap activity.
5. Controls. Same day, same host: an engaged-RC healthy session (different model) ran background tasks all day, zero cancellations. Same build, RC registered but never engaged: a 9-hour signal-trapping probe (540 one-minute beats) plus ~10 other background tasks, zero cancellations, natural exit. These are baseline cells, not treatment tests — stated as such.

What we are NOT claiming

• Not claiming the literal TaskStop implementation is invoked — only that the terminal state and notification formatting match harness-internal cancellation semantics.
• Not claiming every bridge event kills tasks (most don't).
• Alternative internal mechanisms consistent with our data, for your triage: a shared AbortController/parent cancellation scope; bridge-generation replacement/ownership fencing sweeping "stale" tasks; a higher-level session reset that produces BOTH the bridge re-registration and the cancellation (bridge entry as co-effect); server-sent cancellation on reconnect.

Steps to reproduce (offered protocol — we can run this on request)

Deterministic single-cycle version using a local TLS-terminating proxy (preserves the RC host-gate since ANTHROPIC_BASE_URL stays unset):

1. Start Claude Code v2.1.212 with --debug; enable and engage Remote Control (allow initial create + v2 transport to succeed).
2. Launch one long-running run_in_background heartbeat probe; verify it beats.
3. Force-close the v2 transport.
4. Arm A (treatment): proxy injects 401 on the next three POST /v1/code/sessions attempts, then allows 200.
5. Arm B (control): same transport close, all creates return 200.
6. No user, remote, or model cancellation input in either arm.
7. Observe per arm: does the probe receive status:killed? Does its PID terminate? Expected if the hypothesis holds: cancellations in Arm A, none in Arm B.

Expected behavior

RC transport/auth/bridge recovery should be isolated from local background-task lifecycle. A background task should end only on natural exit, process failure, explicit TaskStop, or intentional session shutdown. If RC recovery cannot proceed, surface an RC error and retry/disable RC — don't cancel unrelated background work.

Actual behavior

During a subset of RC failure/re-registration transitions, in-flight background tasks are internally stopped with status:killed and no corresponding command; work in progress is lost and the watchers/monitors pattern becomes unreliable in any session whose RC is flapping.

Impact / severity

High for unattended/orchestration workflows (background watchers silently die precisely in degraded-RC sessions — the sessions that most need them); suggest P1 while the server-side 401 flap is live (that flap is itself worth a linked server-side look; we have request IDs). Not P0 — interactive use is unaffected and a workaround exists (external watchers).

Additional context

Two related observations from the same investigation, available on request: (a) the RC create-endpoint 401 non-determinism dataset (curl, fresh connections, both accounts); (b) none of the four cancellations produced any RC-failure system event in the transcript — RC failures generally persist no transcript record, which made this diagnosis substantially harder (a small observability request: record bridge lifecycle transitions with timestamps).