[BUG] Orphaned background agent when context limit triggers early due to percentage mismatch #18981

Preflight Checklist

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

🐛 What's Wrong?

Background agents become orphaned and consume 100%+ CPU indefinitely when "Context limit reached" triggers prematurely due to the context percentage mismatch bug (#18241).

The cleanup mechanism that should terminate background agents appears to check a different context metric than the one triggering "Context limit reached":

┌─────────────────────────────────────────────────────────────────┐
│  System A (Input Gate)     →  "Context limit reached" triggered │
│  System B (Cleanup Gate)   →  Sees 15% free, no cleanup needed  │
│  Background Agent          →  Orphaned, runs forever            │
└─────────────────────────────────────────────────────────────────┘

📊 Evidence of Mismatch

/context output immediately before "Context limit reached":

Context Usage
claude-opus-4-5-20251101 · 168k/200k tokens (84%)

⛁ System prompt: 3.1k tokens (1.5%)
⛁ System tools: 16.3k tokens (8.1%)
⛁ Memory files: 13.8k tokens (6.9%)
⛁ Skills: 44 tokens (0.0%)
⛁ Messages: 134.5k tokens (67.2%)
⛁ Compact buffer: 3.0k tokens (1.5%)
⛶ Free space: 29k (14.7%)               ← Says 14.7% free

Context low (1% remaining)               ← Says 1% remaining

Then immediately on next tool call:

● Bash(ip netns list | grep detect)
  ⎿  No orphaned detect namespaces or processes
  ⎿  Context limit reached · /compact or /clear to continue

The Inconsistency

These cannot all be true simultaneously.

💀 Observed Orphan Behavior

After "Context limit reached", the background process continued for 2+ hours:

Process only terminated when manually sent SIGUSR2 during investigation.

📋 Session Details

Session ID:     abdca6d7-a612-4545-87aa-00045d864820
Session start:  2026-01-18T06:01:47Z
Process start:  2026-01-18T06:02:56Z  (+1 min)
Last activity:  2026-01-18T08:23:59Z
Process killed: 2026-01-18T08:30:XXZ  (still at 111% CPU after 2+ hours)
Subagents:      5 spawned during session

✅ What Should Happen?

1. Consistent metrics — All context percentage displays should agree ([BUG] Context percentage mismatch between /context, statusline API, and internal limit trigger #18241)
2. Atomic cleanup — When ANY "Context limit reached" fires, ALL background agents terminate
3. No threshold dependency — Cleanup should trigger on the limit event itself, not a separate percentage check

🔗 Related Issues

This bug is the intersection:

#18241's percentage mismatch prevents #17391's cleanup logic from triggering

🖥️ Environment

🔍 Additional Notes

• Orphaned process was in ep_poll state — waiting for epoll events that never arrive
• Responded to SIGUSR2 by terminating (no custom handler) — confirms it wasn't stuck, just abandoned
• No stack trace available — process exited on signal before gdb could attach
• The 156 min CPU time vs 142 min wall time suggests sustained multi-core usage