Subagent kernel wedged in C-level code is abandoned by headless busy-cancel and spins at 100% CPU forever

[cj848]

Description

A subagent (headless rlm child) gets its own Python kernel process spawned by the parent agent process. If that kernel gets wedged inside a single C-level call — observed with catastrophic regex backtracking, where the interpreter never returns to the eval loop and holds the GIL — then:

• it cannot read the stdin protocol interrupt frame, and
• it cannot run the parked SIGINT handler,

so neither in-band interrupt mechanism can reach it. After the busy-reuse window expires, KernelBusyAfterInterruptError is thrown. In a headless context there is no UI, so chooseBusyKernelAction() returns "cancel": the tool call fails, but the kernel manager is never disposed (no shutdown(), no kill).

The kernel process then spins at one full CPU core indefinitely while the parent agent keeps working on replacement kernels. Observed a wedged subagent kernel pinned at ~100% CPU for ~50 minutes until it was killed manually; nothing reclaims it earlier because the parent process stays alive, and the orphan-process reaper only covers bash() grandchildren, not the kernel process itself.

A milder variant of the same leak: when a subagent session ends normally, its kernel process also survives (idle, memory-only cost) as long as the parent process lives.

Steps to reproduce

1. Start an interactive prime-agent session (npm install).

2. Spawn a headless subagent so its kernel starts, e.g. handle = await rlm('sub-task', name='wedge-test').

3. In that subagent, run an ipython cell that wedges inside a C call, for example:

   import re
   re.search(r'(a+)+$', 'a' * 40 + 'b')  # exponential backtracking, never returns

4. Let the subagent's turn abort / time out, or delete the subagent while the cell is still running.

5. The subagent fails and the parent continues on other kernels, but the subagent's kernel process (kernel-venv/bin/python -m rlm.repl) stays alive at ~100% CPU forever. ps confirms it is pinned; killing it manually is harmless to the parent (a fresh kernel is spawned on next use).

Expected behavior

• A kernel that stays busy through the interrupt window in a headless context should be killed and replaced after a grace period (or at latest when its subagent session ends or is deleted).
• Subagent kernel managers should be disposed when the subagent session ends.

Actual behavior

• Headless busy path returns "cancel" and abandons the manager (suspected area: chooseBusyKernelAction in packages/coding-agent/src/core/tools/ipython.ts).
• Nothing disposes it afterwards: the orphan-process journal only has the spawn-time active: true record for the wedged kernel — no inactive record — meaning the teardown/cleanup path never ran for it.

Workaround

An external watchdog that kills rlm.repl processes sustaining ~100% CPU past a threshold (e.g. ≥90% with ≥300s cumulative CPU time).

Environment

• Prime Agent version: 0.9.1 (also confirmed chooseBusyKernelAction is unchanged on current main)
• Installation method: npm package
• OS: macOS 26.6, arm64
• Shell/terminal: zsh in an embedded terminal