Summary
If a session has a pending exec approval and the user starts a new session with /new or /reset before that approval resolves, the eventual approval follow-up can be delivered into the new session. This shows up as unrelated stale approval messages, Exec denied, or continuation text in a fresh conversation.
Affected version
OpenClaw 2026.3.31
Observed behavior
The exec approval follow-up is effectively routed by logical sessionKey. After /new or /reset, the same sessionKey can point to a new sessionId, so when the old approval finishes its follow-up can land in the new session transcript.
Expected behavior
The follow-up should stay bound to the original session instance. Once that sessionKey has been rebound to a different sessionId, stale follow-ups should be dropped instead of being delivered into the new session.
Reproduction
- Start a session for an agent with a stable
sessionKey.
- Trigger a tool execution that requires approval and leave it pending.
- Before approving or denying it, send
/new or /reset, creating a new sessionId under the same logical session key.
- Approve or deny the old request.
- Observe that the new session can receive the old approval follow-up or stale approval-related output.
Root cause
The follow-up path only tracked sessionKey, not the original sessionId that was active when the exec request was created.
Proposed fix
Capture expectedSessionId when creating the exec approval follow-up target, then before sending compare it with the latest sessionKey -> sessionId mapping. If they differ, log and drop the stale follow-up.
Validation
I reproduced this locally, applied that guard in the installed dist, restarted the gateway, and verified that a previously pending approval no longer polluted the new session after /reset.
Concrete validation data from the local repro:
- pending approval id:
21abfe34-9309-40bb-9a2b-9a43349d4d79
- old session id before reset:
59ada67a-ec92-4955-b3f5-b894be448e13
- new session id after reset:
6884416d-17e1-402a-870b-0b6a24762c4c
If helpful, I can also turn the validated local fix into a source-level PR.
Summary
If a session has a pending exec approval and the user starts a new session with
/newor/resetbefore that approval resolves, the eventual approval follow-up can be delivered into the new session. This shows up as unrelated stale approval messages,Exec denied, or continuation text in a fresh conversation.Affected version
OpenClaw 2026.3.31
Observed behavior
The exec approval follow-up is effectively routed by logical
sessionKey. After/newor/reset, the samesessionKeycan point to a newsessionId, so when the old approval finishes its follow-up can land in the new session transcript.Expected behavior
The follow-up should stay bound to the original session instance. Once that
sessionKeyhas been rebound to a differentsessionId, stale follow-ups should be dropped instead of being delivered into the new session.Reproduction
sessionKey./newor/reset, creating a newsessionIdunder the same logical session key.Root cause
The follow-up path only tracked
sessionKey, not the originalsessionIdthat was active when the exec request was created.Proposed fix
Capture
expectedSessionIdwhen creating the exec approval follow-up target, then before sending compare it with the latestsessionKey -> sessionIdmapping. If they differ, log and drop the stale follow-up.Validation
I reproduced this locally, applied that guard in the installed dist, restarted the gateway, and verified that a previously pending approval no longer polluted the new session after
/reset.Concrete validation data from the local repro:
21abfe34-9309-40bb-9a2b-9a43349d4d7959ada67a-ec92-4955-b3f5-b894be448e136884416d-17e1-402a-870b-0b6a24762c4cIf helpful, I can also turn the validated local fix into a source-level PR.