fix(security): cancel RLM work on host teardown

[sethkarten]

Summary

• abort in-flight kernel host requests during kernel disposal, kill, and stop
• propagate the host abort signal through the typed rlm.run bridge
• cancel an already-admitted child run exactly once when its kernel host disappears, and remove listeners after settlement

This is the host-cancellation portion extracted from #1159 and proposed directly against current main.

Risk

Medium. Cancellation remains cooperative; an unresponsive child can outlive the cancellation request until the existing bounded kernel-disposal wait expires. The new behavior only applies when the owning kernel host is torn down.

Provenance

Extracted from independently authored commits a3ba5dba6e8c280caa20cdca88f057810c35bb1a and 8d47a2e9191b6d2b516c979b19c7a8fb9b3b2999 in #1159. Their exact SHAs are recorded in the commit message. The separate clipboard changes from the first source commit are intentionally excluded here.

Validation

• npm run check
• npm run test -- test/agent-session-recursion.test.ts — 97 passed
• focused Biome check on all changed TypeScript files
• git diff --check origin/main...HEAD

Review focus

Please focus on abort-signal lifetime, listener cleanup, idempotent child cancellation, and disposal/restart ordering.

---

Note

^{Cursor Bugbot is generating a summary for commit ee15990. Configure here.}

Note

Cancel in-flight RLM child runs when the kernel host is torn down

• Adds an AbortController (hostRequestController) to KernelManager that is aborted on shutdown, kill, dispose, and cleanup, propagating a reason-specific error to all in-flight host requests.
• Extends HostRequestHandler, handleHostRequest, runRlmChild, and _startRlmChildRun to accept and forward an optional AbortSignal, so cancellation reaches the RLM child run.
• _startRlmChildRun now checks for abort before authentication/model resolution and before session-name assertion, and registers an abort listener that marks the run as cancelled with the abort reason.
• A fresh AbortController is created on doStart if the previous one was already aborted, so restarted kernels are not pre-aborted.
• Risk: any in-flight rlm.run subagent work will be cancelled (and marked cancelled) whenever the kernel shuts down, is killed, or is disposed — previously these runs would continue until they completed or timed out.

📊 Macroscope summarized ee15990. 3 files reviewed, 0 issues evaluated, 0 issues filtered, 0 comments posted

🗂️ Filtered Issues

No issues evaluated.

[macroscopeapp]

🟡 Medium kernel/index.ts:1520

In-flight host requests (e.g. rlm.run) continue running for up to 5 seconds during disposal because abortHostRequests is called after flushSnapshotForDispose(). The snapshot enqueues via enqueueExecute, which serializes behind the busy host-request execution. Since the abort signal hasn't been delivered yet, the snapshot flush blocks on its SNAPSHOT_DISPOSE_TIMEOUT_MS guard before abortHostRequests ever fires. Move abortHostRequests before the flush so the host request is cancelled immediately and the snapshot can proceed (or skip) without the 5-second stall. The same ordering issue exists in shutdown() (line 1374) when opts.snapshot is true.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @packages/coding-agent/src/core/kernel/index.ts around line 1520:

In-flight host requests (e.g. `rlm.run`) continue running for up to 5 seconds during disposal because `abortHostRequests` is called *after* `flushSnapshotForDispose()`. The snapshot enqueues via `enqueueExecute`, which serializes behind the busy host-request execution. Since the abort signal hasn't been delivered yet, the snapshot flush blocks on its `SNAPSHOT_DISPOSE_TIMEOUT_MS` guard before `abortHostRequests` ever fires. Move `abortHostRequests` before the flush so the host request is cancelled immediately and the snapshot can proceed (or skip) without the 5-second stall. The same ordering issue exists in `shutdown()` (line 1374) when `opts.snapshot` is true.