Background tasks persist after /clear and cannot be stopped via programmatic Ctrl+C/Escape

Description

When a Claude Code instance has background tasks running, they cannot be reliably stopped through programmatic means (e.g., sending keystrokes via iTerm2's it2 session send-text). The background tasks persist and respawn even after:

1. Killing the underlying OS processes (sleep, curl, python) spawned by the background tasks
2. Sending Ctrl+C (\x03) via it2 session send-text
3. Sending Escape (\x1b) via it2 session send-text
4. Sending Ctrl+X Ctrl+K (\x18\x0b) — the "stop agent" shortcut shown in the status bar
5. Running /clear — this cleared conversation context but the 2 background tasks remained active and Claude continued "Pondering..." for over 1 minute

Expected behavior

• /clear should cancel all pending background tasks
• Ctrl+X Ctrl+K sent programmatically should stop the agent and its background tasks
• Killing the child processes of background tasks should cause Claude Code to recognize they've terminated, not respawn new ones

Actual behavior

• Background tasks continued to show "2 background tasks" in the status bar even after their underlying processes were killed
• Claude Code appeared to respawn monitoring processes (new sleep + check commands) after the originals were killed
• The only way to stop it was sending /exit to terminate the entire Claude Code session

Reproduction steps

1. Start a Claude Code session
2. Give it a task that spawns long-running background commands (e.g., sleep 2450 && ...)
3. From another terminal, kill the background processes via kill <PID>
4. Observe that Claude Code spawns new background monitoring processes
5. Try sending /clear, Ctrl+C, Escape, Ctrl+X Ctrl+K via it2 session send-text — none stop the background tasks

Environment

• Claude Code v2.1.92
• Opus 4.6 (1M context) · Claude Max
• macOS Darwin 24.1.0
• iTerm2 with it2 session send-text for programmatic input
• Multi-pane setup with 4 Claude Code instances communicating via iTerm2 session IDs

Additional context

This occurred in a multi-agent setup where one instance (A4) delegated work to another (A1) via it2 session send-text. When A4 completed the work centrally and tried to stop A1, it was unable to do so through any programmatic means except /exit.