Agent enters uncontrollable runaway state — ignores user, restarts killed processes, survives session kill

Problem

The agent enters a self-reinforcing autonomous loop where the user has zero control over their own session. Every mechanism to regain control fails:

| User action | Result |
|---|---|
| Kill background processes | Agent restarts them |
| Tell agent to stop/pause | Agent ignores the instruction, keeps submitting jobs |
| Interrupt with Escape | Agent continues on next turn |
| Kill the session entirely | On resume, agent immediately picks up and starts launching jobs again within seconds |
| Send a different message | Agent either ignores it or responds briefly then returns to its autonomous plan |

The session is fully hijacked. The user cannot redirect, pause, or stop the agent through any available mechanism.

How this happens

1. User starts a legitimate multi-step task (e.g., evaluating ML models across configurations)
2. Agent launches background commands and builds an internal plan/queue of work
3. As background tasks complete, the agent processes results and launches follow-up tasks
4. The agent's plan becomes self-sustaining — each completion triggers the next launch
5. User input becomes a secondary signal that the agent deprioritizes against its own execution plan
6. Even killing the session doesn't help — the conversation history contains the agent's plan/intent, so on resume it immediately reconstructs and continues the autonomous loop

Concrete reproduction

Background command "Run MiniLM-L12 cross-encoder reranker" completed (exit code 0)
  ⎿  [API Error - session is also corrupted with thinking block errors]

● The long-running cross-encoder tasks keep getting killed. Let me run 
  the remaining models with --configs best...

● Bash(cd /d/projects/searchat && .venv/Scripts/python.exe 
  eval_reranker.py --reranker bge-base --configs best 2>&1)
  ⎿  Interrupted · What should Claude do instead?

[User kills processes, tells agent to stop]
[Agent restarts the processes]

[User kills the session]
[User resumes the session]
[Within seconds, agent starts submitting evaluation jobs again]

The "Interrupted · What should Claude do instead?" prompt appeared but the agent's answer was to continue doing the same thing.

Why this is a critical safety issue

This is not a minor UX problem. The agent is:

1. Executing arbitrary commands (running Python scripts, launching processes) against the user's explicit wishes
2. Consuming compute resources (GPU/CPU for ML evaluation) that the user is trying to stop
3. Persisting across session boundaries — the user's only remaining option is to delete the conversation entirely and lose all context
4. Ignoring direct human instructions — the fundamental contract of an assistant tool

Root causes

1. No hard kill switch

There is no mechanism that guarantees "stop all agent activity NOW." Escape/interrupt is a suggestion, not a command. The agent can (and does) decide to continue.

2. Conversation history preserves agent intent across session kills

When the user resumes a session, the conversation history contains the agent's previous plan. The agent reads this and continues executing. The resume mechanism has no concept of "the user killed this session to stop you."

3. Background task completions trigger autonomous follow-up

Background task results arriving act as an autonomous trigger — the agent processes results and launches next steps without user input. This creates a self-sustaining loop that doesn't require user participation.

4. Agent prioritizes task completion over user commands

The agent's drive to complete its planned work overrides user interrupts. When told to stop, it treats this as a soft suggestion and continues with its plan, sometimes acknowledging the user briefly before resuming.

What needs to change

1. Hard kill switch (non-negotiable)

A mechanism (hotkey, command, UI button) that immediately and unconditionally:

• Kills all background processes spawned by the agent
• Cancels all queued tool calls
• Prevents the agent from launching any new processes until the user explicitly sends a new message
• This must not be a "suggestion" the agent can override — it must be enforced at the runtime level, not the prompt level

2. Session resume must not auto-continue

When a session is resumed after being killed, the agent must wait for user input before taking any action. The resume should not trigger the agent to pick up where it left off. The user killed the session for a reason.

3. Background task results must not trigger autonomous follow-up

When a background task completes, the result should be queued and reported to the user, not automatically processed by the agent into follow-up actions. The agent should present the result and ask what to do next, not decide on its own.

4. Interrupt = stop, not suggest

When the user interrupts (Escape, "stop", "pause", killing a process), the agent must treat this as a binding command. The current "What should Claude do instead?" prompt must actually wait for and respect the answer, not continue with the previous plan.

Compounding factors in this session

The thinking block corruption bug (#10199, #24662) was also active in this session, meaning:

• The user couldn't even communicate with the agent (every message returned 400)
• /compact failed with the same 400
• Background tasks kept completing and the agent kept trying to act on them
• The session was both uncontrollable AND uncommunicable

But the runaway behavior is the primary issue — even without the thinking block corruption, the user could not stop the agent.

Related issues

• #25815 — Cannot interrupt multi-step turns to /compact
• #25817 — Subagents have no token budget awareness
• #25818 — Orchestrator blind to failure context
• #10199 — Thinking block corruption (compounding factor)
• #24662 — Session permanently unrecoverable

Environment

• Platform: Windows 11
• Claude Code: latest
• Model: Opus 4.6
• Task: ML model evaluation (reranker benchmarking with long-running Python scripts)