Summary

• Problem: Issue [Bug] Exec approval follow-up can leak into a new session after /new because it rebinds by sessionKey instead of original sessionId #59349 reports that if a session has a pending exec approval and the user runs /new or /reset before resolving it, the eventual approval follow-up can be delivered into the new session. It surfaces as stale approval messages, Exec denied, or continuation text appearing in an unrelated fresh conversation. The bug is observed across elevated and non-elevated approvals on every channel that routes through /v1/chat/completions or the agent-command pipeline.
• Root Cause: The follow-up is dispatched by logical sessionKey only (the agent follow-up request carries the key, not the originating session instance). The gateway resolves that key to whatever sessionId it currently maps to at follow-up time. /new and /reset rotate the sessionId under the same key, so a follow-up created while the original session was active resolves to the new session and lands there. The session instance active when the approval was requested was never captured or compared, so there was nothing to detect the rebind. CWE-200 information leak: old approval output reaches a fresh user-facing conversation.
• Fix: Capture the session UUID active when the approval is requested (the run's sessionId, regenerated on /new and /reset) and thread it from the exec tool through the exec hosts onto the follow-up target. Drop the follow-up once that key has been rebound to a different session id, on both delivery paths:
  • Agent-run follow-ups (resume path): forward the expected id on the follow-up agent request as a new optional field execApprovalFollowupExpectedSessionId, and drop it at the gateway as an early preflight — before the handler touches the rebound session at all (session-store write, chat/agent run + active-run registration, dedupe, accepted ack), not just before model dispatch. So a stale follow-up leaves the rebound session completely untouched. Because the id rides on the request (not only on the elevated runtime handoff), it covers both elevated and non-elevated approvals.
  • Denied / direct fallback follow-ups (the Exec denied and direct-send path, which never reaches the gateway): resolve the key's current session id from the session store and drop the follow-up before the channel send. The session.store template is threaded through so custom store locations resolve correctly.
• What changed:
  • src/agents/bash-tools.exec-types.ts: add sessionId and the session.store template to ExecToolDefaults.
  • src/agents/agent-tools.ts: forward the run's session id and store template into the exec tool defaults.
  • src/agents/bash-tools.exec.ts, bash-tools.exec-host-gateway.ts, bash-tools.exec-host-node.ts, bash-tools.exec-host-node.types.ts: thread the session id and store template to buildExecApprovalFollowupTarget.
  • src/agents/bash-tools.exec-host-shared.ts: carry expectedSessionId and the store template on the follow-up target and forward them to the dispatch.
  • src/agents/bash-tools.exec-approval-followup.ts: include execApprovalFollowupExpectedSessionId on the follow-up agent request, and drop denied/direct fallback sends when the key resolves to a different session id.
  • src/agents/bash-tools.exec-approval-followup-state.ts: add the isExecApprovalFollowupSessionRebound decision helper.
  • packages/gateway-protocol/src/schema/agent.ts: add the optional request field (additive only).
  • src/gateway/server-methods/agent.ts: drop the follow-up as an early preflight when the session key was rebound — before any session-store write, run/context/active-run registration, dedupe, or accepted ack.
  • apps/shared/OpenClawKit/Sources/OpenClawProtocol/GatewayModels.swift: protocol model mirror for the new optional field.
  • src/agents/bash-tools.exec-host-shared.test.ts, bash-tools.exec-approval-followup.test.ts: regression coverage for both delivery paths (rebound / unchanged / missing-id).
  • src/gateway/server-methods/agent.test.ts: focused gateway integration test asserting that a stale exec-approval followup is dropped at preflight without any side effect on the rebound session — response is {status: "ok", summary: "exec approval followup dropped: ..."}, dedupe entry is seeded with that payload, and neither mocks.updateSessionStore nor mocks.agentCommand is invoked.
• What did NOT change (scope boundary):
  • Runtime handoff registration, deterministic follow-up idempotency, and exec execution — untouched. The drop only fires when an expected session id is present and differs from the resolved session id, so non-rebound and id-less follow-ups deliver exactly as before.
  • Steady-state established sessions are unaffected (the expected id matches the resolved id, so nothing is dropped).
  • Gateway protocol change is additive only (one optional request field on agentRequest); no key is retired, no version bump required, existing clients unaffected.
  • No config keys, doctor migrations, plugin SDK, streaming, or delivery behavior changed.
  • No package.json / pnpm-lock.yaml / npm-shrinkwrap.json / pnpm-workspace.yaml edits; Dependency Guard not applicable.
  • No CHANGELOG.md edit (release-owned).

Reproduction

1. Start a session for an agent with a stable session key.
2. Trigger a tool execution that requires approval and leave it pending.
3. Before approving, send /new or /reset, creating a new sessionId under the same key.
4. Approve the old request.

• Before: the new session receives the old approval follow-up (a follow-up run enters the agent pipeline for the rebound session) — stale approval output, Exec denied, or continuation text surfaces in an unrelated fresh conversation.
• After: the gateway detects the rebind and drops the stale follow-up before any session-store write, run registration, or model dispatch; the new session is not polluted.

Real behavior proof

• Behavior addressed: an exec approval follow-up whose session key was rebound by /new or /reset while the approval was pending must be dropped at the gateway (resume path) or in the agents layer (denied/direct path) instead of being delivered into the new session.
• Real environment tested: a real OpenClaw gateway started in-process via startGatewayServer on loopback (bundled plugins disabled for fast startup; channels/providers/cron skipped), driven over a real operator WebSocket connection. Linux x64, Node 22. Real performGatewaySessionReset + real exec.approval.resolve operator RPC + real on-disk session-store JSON.
• Exact steps or command run after this patch: seed session key agent:main:main to session id 11111111-...-111111111111; start the gateway and connect an operator; build the gateway exec tool for that session (agent follow-up mode, ask: always) and run a command requiring approval, leaving it pending; call the real reset path performGatewaySessionReset({ key, reason: "reset" }) to rotate the key to a new session id; resolve the pending approval via the exec.approval.resolve operator RPC; observe the gateway log + re-read the session store. Unit-level regression: node scripts/run-vitest.mjs src/agents/bash-tools.exec-approval-followup.test.ts src/agents/bash-tools.exec-host-shared.test.ts.
• Evidence after fix (verbatim live console output, color codes stripped; [REPRO] = harness script markers, [gateway] / [agents/exec-approval-followup] = OpenClaw runtime logs):

=== SCENARIO 1 — resume path (agent-run follow-up dropped at gateway preflight) ===
[REPRO] exec pending status: approval-pending
[REPRO] approvalId: afb796ab-f635-45f7-b7f1-37224a429aff
[REPRO] after reset: agent:main:main -> e3870fca-ac72-4efc-943b-e4c24c64bce2 reset.ok= true
[REPRO] resolving approval (allow-once) ...
[gateway] Dropping stale exec approval followup afb796ab-f635-45f7-b7f1-37224a429aff: session agent:main:main rebound (expected 11111111-1111-4111-8111-111111111111, resolved e3870fca-ac72-4efc-943b-e4c24c64bce2) before the approval resolved

=== SCENARIO 2 — rebound session untouched (no session-store write happens for the dropped follow-up) ===
[REPRO] after reset: agent:main:main -> 471d713c-b3c8-4910-b7c7-e60f0ecdc024 updatedAt= 1779553025393
[gateway] Dropping stale exec approval followup adfbf4a7-...: session agent:main:main rebound (expected 33333333-..., current 471d713c-...) before the approval resolved
[REPRO] after followup: agent:main:main -> 471d713c-b3c8-4910-b7c7-e60f0ecdc024 updatedAt= 1779553025393
[REPRO] REBOUND SESSION UNTOUCHED (updatedAt unchanged, stale followup dropped before any store write)

=== SCENARIO 3 — denied/direct path (no gateway send; agents-layer drop) ===
[REPRO] exec pending status: approval-pending
[REPRO] approvalId: 47c60a91-b795-458e-8263-907e5c5aa6c2
[REPRO] after reset: agent:main:main -> 0a2007ac-162c-40f1-be21-938cf4ee1126 reset.ok= true
[REPRO] DENYING approval after reset ...
[agents/exec-approval-followup] Dropping stale denied exec approval followup 47c60a91-b795-458e-8263-907e5c5aa6c2: session agent:main:main was rebound before the approval resolved

=== BASELINE (same scenario on the pre-fix base commit) — no drop happens; follow-up enters the run pipeline ===
[REPRO] approvalId: 0fb830d1-adc1-4a4e-9880-fe2563fb13a5
[REPRO] after reset: agent:main:main -> d762ec2c-fd60-49d6-b932-9bc41e6fef27 reset.ok= true
exec approval followup dispatch failed (id=0fb830d1-adc1-4a4e-9880-fe2563fb13a5): Session followup failed: gateway closed (1012): service restart
[ws] res agent errorCode=UNAVAILABLE errorMessage=FailoverError: No API key found for provider "openai" ... runId=exec-approval-followup:0fb830d1-adc1-4a4e-9880-fe2563fb13a5

• Observed result after fix: the gateway recognized the session rebind (expected original id vs resolved new id), logged the drop at the preflight, and did not dispatch a follow-up run into the new session. The session-store entry for the rebound key is byte-identical before and after the dropped follow-up (updatedAt unchanged), proving no run/store/dedupe/ack side effects on the rebound session. The denied/direct path equivalent is dropped one layer earlier in the agents code so no channel send occurs. The pre-fix baseline shows the same scenario unconditionally dispatching a follow-up agent run (runId=exec-approval-followup:0fb830d1-...) into the rebound session.
• Code-path coverage: node scripts/run-vitest.mjs src/agents/bash-tools.exec-approval-followup.test.ts src/agents/bash-tools.exec-host-shared.test.ts (86 passed across 4 files) covers rebound / unchanged / missing-id branches on the predicate, the followup-target thread-through, and the denied/direct fallback path. node scripts/run-vitest.mjs src/gateway/server-methods/agent.test.ts -t 'drops a stale exec approval followup at preflight' (2 passed) locks the gateway preflight invariant — drop response shape, dedupe seed, and the absence of updateSessionStore / agentCommand calls — in regression tests. Bite check confirmed: temporarily disabling the preflight makes the new gateway test fail with status: "accepted" (followup dispatched into the rebound session), which is exactly the pre-fix behavior the predicate is supposed to prevent. pnpm exec oxfmt --check and pnpm exec oxlint on the touched TypeScript files are clean.
• What was not tested: bundled plugins were disabled and no model API key was configured in the in-process gateway test environment; the dropped-follow-up path returns before any model invocation, so model-auth-side concerns are out of scope. A multi-hour production deployment and a third-party channel end-to-end were not exercised. Cross-PR merge order with fix(agents): serialize new-session resolution per session key #85404 / [Fix] Deliver restart recovery replies #86089 / fix(agents): persist user turn before attempt failures #86764 was not simulated end-to-end, but the branch rebases cleanly onto current origin/main with the single import-merge conflict resolved.

Risk / Mitigation

• Risk: dropping a follow-up could suppress a legitimate one if the expected id is wrong. Mitigation: the drop only fires when an expected session id is present and differs from the resolved session id (unit tests cover rebound / unchanged / missing-id branches). Id-less follow-ups deliver unchanged, so backwards compatibility for callers that do not opt in is preserved.
• Risk: the new protocol request field could be misread by older clients. Mitigation: the field is optional and additive on agentRequest; no key is retired, no version bump required. Existing clients that do not send the field hit the existing delivery path. The Swift OpenClawProtocol mirror is updated in lockstep so iOS clients deserialize cleanly.
• Risk: the early preflight changes session-state timing for rebound keys (drop happens before any handler write, run registration, or dedupe). Mitigation: that is the documented contract this PR introduces, and it is strictly stronger than the pre-fix behavior — every effect that used to land on the rebound session is now suppressed at one explicit point, with a verbatim log line. Scenario 2 above shows the rebound session's updatedAt is unchanged across the drop.
• Risk: cross-PR conflict with sibling PRs fix(agents): serialize new-session resolution per session key #85404 / [Fix] Deliver restart recovery replies #86089 / fix(agents): persist user turn before attempt failures #86764 in adjacent regions of src/agents/agent-command.ts and bash-tools.*. Mitigation: this branch rebases cleanly onto current origin/main after resolving one import-merge in bash-tools.exec-approval-followup.ts (combine the new isExecApprovalFollowupSessionRebound import with main's renamed embedded-agent-helpers/sanitize-user-facing-text path). Merge order with the sibling PRs is independent.

Change Type (select all)

• Bug fix

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• API / contracts

Linked Issue/PR

Fixes #59349