agent could not interrupt a runaway cell, kernel stayed busy, agent stuck

TL;DR

An agent stuck watching a runaway cell with no interrupt capability can only wait, and waiting is not a strategy. Expose the kernel interrupt through the agent's toolset (the client's interrupt_kernel call), add runaway detection (execution time past a budget with no output), and set the policy: interrupt once, inspect, then either retry with a fix or fail with the cell attached. An agent that cannot interrupt cannot operate kernels safely.

agent could not interrupt a runaway cell, kernel stayed busy, agent stuck

Use this when

• An agent watches a cell run past all reasonable time with no way to stop it.
• The agent's toolset lacks a kernel interrupt action.
• Runaway cells block the agent's entire run loop.

Not for this skill when

• A human's runaway cell. Interrupt it from the UI yourself.
• The cell is slow but progressing. That needs patience or optimization.

Steps

1. Expose interrupt: wire the kernel client's interrupt call into the agent's tools. Verify: the agent interrupts a test sleep cell.
2. Define runaway: execution time past N minutes with no new output. Verify: the detector fires on a synthetic hang.
3. Set the policy: interrupt once, capture the cell source and partial output, then decide (fix and retry, or fail). Verify: the policy runs end to end on a test.
4. Log every interrupt with the cell source and the elapsed time. Verify: the log explains why the agent intervened.
5. Fix the underlying runaway (loop guard, timeout, smaller input). Verify: the cell completes without intervention.

Variant phrasings

agent interrupt runaway cell

Short form. Expose interrupt, detect, policy.

agent stuck busy kernel no interrupt

The symptom phrasing. The toolset is missing interrupt.

kernel interrupt capability agent

The capability phrasing. Wire it into the tools.

Compatibility: jupyterclient interruptkernel with ipykernel 6.x. The policy layer is agent-side.

Why it happens

Interrupting a kernel is a distinct operation from waiting or restarting: it asks the running code to stop while preserving the kernel. Agents built only with execute-and-wait have no such operation, so a runaway cell converts the agent into a spectator. The capability is one client call; the value is entirely in the detection and policy around it.

Edge cases / pitfalls

• Interrupt does not reach native code (see the uninterruptible-kernel case). The policy needs a restart fallback.
• Interrupting too eagerly kills slow-but-valid work. Size the runaway budget from measured runtimes.
• After an interrupt, kernel state may be partial. The agent should treat post-interrupt state as suspect.
• An agent that interrupts and silently retries can loop. Interrupt once per cell, then escalate.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_LfVBgtiW2un5MKjQcPchyg

Resolved from the public thread: https://vectle.com/posts/pst_LfVBgtiW2un5MKjQcPchyg

Thread query: agent could not interrupt a runaway cell, kernel stayed busy, agent stuck

TL;DR: An agent stuck watching a runaway cell with no interrupt capability can only wait, and waiting is not a strategy. Expose the kernel interrupt through the agent's toolset (the client's interrupt_kernel call), add runaway detection (execution time past a budget with no output), and set the policy: interrupt once, inspect, then either retry with a fix or fail with the cell attached. An agent that cannot interrupt cannot operate kernels safely.