Background task handles orphaned after context compaction — TaskOutput/TaskStop inoperable on pre-compaction tasks

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

When context compaction fires and creates a new session, background tasks started in the previous session become permanently unreachable to the agent. Task IDs are scoped to the session's in-process task registry; that registry is not serialized or transferred across the compaction boundary. The underlying OS processes continue running, and they remain visible and interactable through the Claude Code UI (the down-arrow background task manager). But the agent's TaskOutput and TaskStop tools can no longer interact with them — the handles are orphaned from the agent's perspective.

The practical consequence: auto-compaction serializes on human intervention. Any background work the agent started before compaction fires must now be managed manually by the user through the UI. The agent cannot poll for results, check status, or cancel those tasks. If the agent was coordinating multiple background agents or long-running processes, the entire coordination model breaks silently — the agent simply cannot know the work completed or what the results were.

This is not a context/memory loss bug. Every existing issue about compaction frames it as an LLM memory problem ("Claude forgets what it read"). This is different: it is an application-layer state management bug in the task registry. Auto-memory systems, better summarization, and CLAUDE.md re-reading cannot fix it. The task handles must be re-registered in the new session's process table.

Steps to Reproduce

1. Start one or more background tasks (Bash tool with run_in_background: true, or Task tool with run_in_background: true)
2. Continue working in the same session until context compaction fires automatically
3. In the post-compaction session, call TaskOutput with any of the pre-compaction task IDs
4. Result: "no such task" — even though the processes are still running at the OS level and still appear in the UI background task list

Expected Behavior

TaskOutput and TaskStop operate on the process handle, not on a session-scoped registry entry. Either:

• (a) the task registry is serialized and restored across the compaction boundary, or
• (b) task IDs are process-scoped rather than session-scoped so they survive compaction

In either case, the agent should have the same access to background tasks that the UI already has.

Actual Behavior

The in-process task registry is silently dropped on compaction. All pre-compaction task IDs return "no such task" to the agent. The tasks remain visible in the UI background task manager and can be managed manually, but the agent is completely blind to them. Background processes may continue running indefinitely with no programmatic way to query or terminate them through Claude Code's agent tooling.

Why This Is Distinct From Related Issues

| Issue | Root Cause | Different Because |
|:------|:-----------|:------------------|
| #28469 | LLM quality regression | Model behavior, not task registry |
| #29160 | Role boundary parsing after compaction | Trust boundary bug, not process handles |
| #27319 | Stale plans re-executed after compaction | LLM context framing, not process registry |
| #25999 | Hook API stability for LLM memory | LLM-layer state, not OS process handles |
| #22882 | Unexpected compaction trigger on terminal close | Compaction trigger conditions, not handle orphaning |

Claude Model

Opus 4.6, Sonnet 4.6

Is this a regression?

I don't know

Claude Code Version

v2.1.59 (observed Feb 26, 2026)

Platform

Anthropic API

Operating System

Linux

Terminal/Shell

zsh

Additional Information

Affects both Bash tool invocations with run_in_background: true and Task tool agent invocations with run_in_background: true. Both create entries in the session task registry that are dropped when compaction spawns a new session.

The asymmetry is notable: the UI's background task manager retains full visibility and control over these tasks post-compaction, which confirms the processes and their metadata are still accessible at the application layer. The gap is specifically in the agent-facing task registry not being reconstituted in the new session.