Session that died mid-turn is silently adopted as a background agent (isMeta "Continue from where you left off." auto-injected), locking the original out of /resume — v2.1.220
Preflight Checklist
- [x] I have searched existing issues. Closest matches: #65969 (closed as COMPLETED — its exact injection signature reproduces here on v2.1.220), #73389 (silent mid-turn session death), #70170 / #74529 / #58725 (daemon-held sessions refuse
/resume), #75448 (in-flight carry-over undocumented). None covers the full causal chain below. - [x] This is a single bug report (one causal chain, evidenced from one session transcript)
- [x] I am using the latest version of Claude Code (2.1.220)
Environment
- Claude Code 2.1.220, terminal CLI (zsh), macOS (Darwin 25.5.0), Apple Silicon
- Long-lived interactive session,
bypassPermissions - No
CLAUDE_DISABLE_ADOPT/CLAUDE_CODE_DISABLE_BACKGROUND_TASKS/CLAUDE_CODE_DISABLE_AGENT_VIEWset at the time (defaults)
What's Wrong?
An interactive session died mid-turn. ~1h47m later the daemon silently adopted it as a background agent and auto-injected a continuation prompt — no confirmation, no visible announcement. From that moment the original conversation was locked out: /resume refused with "still running as a background agent". The user never pressed ←, never ran /bg or /background, never used claude --bg.
The full chain, reconstructed from the session transcript (~/.claude/projects/<project>/24c92df3-c3cb-4767-a63b-4f2b43b9b202.jsonl; timestamps UTC):
1. Silent mid-turn death (signature matches #73389)
At 2026-07-28T02:25:36Z the transcript ends abruptly right after a Bash tool_result (followed only by a system/informational entry). No assistant events follow — the turn was in flight when the session died.
2. Silent adoption + auto-injected continuation (exact signature of #65969, which is closed as COMPLETED — reproducing on 2.1.220, terminal-CLI path)
At 2026-07-28T04:12:31Z, with no user input whatsoever:
{"type":"user","isMeta":true,"timestamp":"2026-07-28T04:12:31.374Z","message":{"content":[{"type":"text","text":"Continue from where you left off."}]}}
{"type":"assistant","timestamp":"2026-07-28T04:12:31.375Z","message":{"content":[{"type":"text","text":"No response requested."}]}}
3. Original session locked out
5 and 21 seconds later, the user's /resume attempts (from the terminal they had just opened) are refused, recorded in the same transcript:
That session is still running as a background agent. Open `claude agents` to attach to it, or stop it there first to resume here.
Per #70170 the interactive claude agents recovery path is unreliable (row unlabeled/blocked), so the only practical reclaim was --resume <id> --fork-session, which creates a divergent copy instead of restoring the original. Additionally, in the adopted session (attached via agent view) Ctrl+V image paste did not attach — same as #64899.
Net effect: the session was carried on in a place the user never asked for, and the original conversation could not be reclaimed in place. This has recurred repeatedly over recent weeks for this user, costing hours of lost context each time.
What Should Happen?
- Adopting a dead session's in-flight work as a background agent should require explicit consent — or at minimum announce itself and offer a one-keystroke reclaim.
CLAUDE_DISABLE_ADOPT=1exists, but silent carry-over is the default and the behavior is essentially undocumented (#75448). /resume/claude --resume <id>against a daemon-held session should offer takeover/foregrounding instead of a bare refusal (same ask as #70170 / #74529 / #58725).- #65969 appears to have regressed or was fixed only for the VS Code entrypoint: the
isMeta"Continue from where you left off."+ synthetic"No response requested."pair still fires on 2.1.220.
Workaround
export CLAUDE_DISABLE_ADOPT=1
export CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1
export CLAUDE_CODE_DISABLE_AGENT_VIEW=1