Summary

• Problem: chat.abort and sessions.abort return {ok: true, aborted: false, runIds: []} for runs started via the public agent RPC, because only chat.send registers its run into context.chatAbortControllers. External apps that drive the Gateway through agent (to get raw lifecycle/tool/approval events or per-run system prompt injection) have no public way to stop an in-flight run.
• Why it matters: safe deployments need a reliable public interrupt for autonomous agent runs; the only current workaround is depending on OpenClaw internals.
• What changed: agent RPC now creates an AbortController, registers it into chatAbortControllers (matching chat.send's entry shape), threads the signal into agentCommandFromIngress, and clears the entry on completion — guarded so it only deletes entries it owns.
• What did NOT change (scope boundary): no protocol changes, no new RPC (reporter's preferred sessions.stop left for a separate design), no change to chat.send / sessions.abort behavior, no change to embedded runner abort plumbing (it already honors abortSignal).

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes [Bug]: chat.abort cannot stop active agent runs; only works for chat.send runs #71128
• Related #
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: dispatchAgentRunFromGateway called agentCommandFromIngress without creating an AbortController or registering into context.chatAbortControllers. chat.abort's lookup (chatAbortControllers.get(runId)) therefore always missed for agent-started runs and returned aborted:false, even while the run was streaming.
• Missing detection / guardrail: no unit test asserted that a run started by the agent RPC could be interrupted by chat.abort; all existing abort coverage went through chat.send.
• Contributing context: chat.send and agent share the concept of a runId / idempotencyKey, and agent.wait already reads chatAbortControllers.has(runId) to detect cross-RPC collisions — so the registry was intended to be populated by both paths; the agent handler simply never wrote to it.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/gateway/server-methods/agent.test.ts (gateway agent handler chat.abort integration describe block).
• Scenario the test should lock in: an agent-started run is abortable via chat.abort both by {sessionKey, runId} and by {sessionKey} alone; the resulting AbortSignal fires; the controller entry is removed after success, error, and abort; the registration does not overwrite or evict an entry owned by a concurrent chat.send with the same runId.
• Why this is the smallest reliable guardrail: the bug is at the gateway handler seam; asserting registration + cleanup + signal wiring at the handler level is enough and avoids booting the full embedded runner.
• Existing test that already covers this: none for the agent path. chat.abort coverage existed only via chat.send.
• If no new test is added, why not: N/A — 7 new tests added.

User-visible / Behavior Changes

• chat.abort({sessionKey, runId}) and sessions.abort({key, runId}) now interrupt in-flight runs started by the agent RPC, returning aborted:true, runIds:[runId]. Before, they returned aborted:false, runIds:[].
• No config, default, or schema changes.

Diagram (if applicable)

Before:
  agent RPC -> runId=X -> dispatch(no abortSignal)
  chat.abort(X)    -> chatAbortControllers.get(X)   -> undefined -> aborted:false

After:
  agent RPC -> runId=X -> register AbortController in chatAbortControllers
                       -> dispatch(ingressOpts.abortSignal = controller.signal)
  chat.abort(X)    -> chatAbortControllers.get(X)   -> entry -> controller.abort()
                   -> run aborts, .finally() clears entry (only if entry.controller === ours)

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No — only adds an interrupt path for runs the caller already started.
• Data access scope changed? No — chat.abort's existing authorization (canRequesterAbortChatRun, admin-or-matching-connId-or-deviceId) is preserved because the registered entry populates ownerConnId / ownerDeviceId from the originating client, same as chat.send.
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: macOS 15.4 (reporter); reproduced locally against HEAD via unit tests on Linux.
• Runtime/container: Node 22+, pnpm openclaw gateway.
• Model/provider: any (reporter: minimax; reproduction is model-agnostic).
• Integration/channel (if any): N/A — affects all direct Gateway RPC clients.
• Relevant config (redacted): default gateway with token auth.

Steps

1. Start a long-running run via agent RPC: {method: "agent", params: {sessionKey, message, idempotencyKey, ...}}.
2. While the run is streaming, call chat.abort({sessionKey, runId}) or sessions.abort({key: sessionKey, runId}).
3. Inspect the RPC response and the subsequent agent lifecycle.

Expected

• RPC returns {ok: true, aborted: true, runIds: [runId]} and the agent run terminates.

Actual (before this PR)

• RPC returns {ok: true, aborted: false, runIds: []}; the run continues.

Evidence

• Failing test/log before + passing after

Verified by temporarily reverting each of (a) the registration block and (b) the cleanup guard, and confirming the new tests fail, then restoring and confirming they pass. Representative failure on the unfixed source:

FAIL  gateway agent handler chat.abort integration > chat.abort by runId aborts the agent run's signal and removes the entry
  expected: { aborted: true, runIds: ["idem-abort-run"] }
  received: { ok: true, aborted: false, runIds: [] }

After the fix, all 40 tests in agent.test.ts pass, plus the full abort-adjacent suite (106/106 across 5 files).

Human Verification (required)

• Verified scenarios:
  • agent run → chat.abort({sessionKey, runId}) → signal fires, entry removed, response reports aborted:true.
  • agent run → chat.abort({sessionKey}) with no runId → session-scoped abort finds and stops the run.
  • agent run completes normally → entry removed in .finally().
  • agent run rejects → entry removed in .finally().
  • agent run with no resolvedSessionKey → registration skipped; no map pollution.
  • Pre-existing chat.send entry with same runId → agent registration skipped; agent completion does NOT evict chat.send's entry.
  • Registration happens before the accepted ack (race-safety against clients that abort immediately on seeing the ack).
• Edge cases checked: owner authorization (ownerConnId / ownerDeviceId populated so canRequesterAbortChatRun respects device scoping); controller-identity guard on cleanup so concurrent chat.send + agent with the same idempotencyKey do not corrupt each other's registration.
• What I did not verify: live end-to-end abort with a real upstream model call (coverage is at the gateway handler seam; the embedded runner already honors abortSignal via preexisting tests, and I did not re-run the full integration suite against a live provider).

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: runId collision between a concurrent chat.send and agent RPC (same idempotencyKey, same session) could in principle cause double-registration or premature cleanup.
  • Mitigation: registration is skipped when chatAbortControllers.has(runId) is already true, and cleanup only deletes entries whose controller matches the one this handler created (explicit test locks this in).
• Risk: agent RPC runs without a resolvedSessionKey (e.g., group-only runs) can't be aborted by chat.abort because chat.abort requires a sessionKey.
  • Mitigation: accepted — matches chat.send's contract; the alternative would require a new session-less abort surface, which is out of scope for this fix (reporter's preferred sessions.stop path).