Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Approved exec command can return unrelated output in subagent context [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#78256•Fetched 2026-05-07 03:39:10
View on GitHub
Comments
1
Participants
2
Timeline
2
Reactions
2
Author
josephbkfungjosephbkfung
Participants
clawsweeper[bot]clawsweeper[bot]josephbkfungjosephbkfung
Timeline (top)
commented ×1cross-referenced ×1

After approving an exec request from a subagent, the command sometimes executes but the returned stdout/stderr is from an unrelated context instead of the approved command. This showed up with SSH reads from gx10-1.

Root Cause

After approving an exec request from a subagent, the command sometimes executes but the returned stdout/stderr is from an unrelated context instead of the approved command. This showed up with SSH reads from gx10-1.

Fix Action

Fixed

PR fix notes

PR #78284: Bind approved exec followups to exact run output

Description (problem / solution / changelog)

Fixes #78256.

Summary

  • thread the approved command text into gateway/node exec approval followups
  • harden successful followup prompts so exact completion details are the only authoritative output
  • add regression coverage for two approved gateway exec runs resolving out of order, proving each followup remains bound to its own approval id, run session id, and output

Verification

  • git diff --check
  • targeted test attempt: node scripts/test-projects.mjs src/agents/bash-tools.exec-host-gateway.test.ts src/agents/bash-tools.exec-approval-followup.test.ts --maxWorkers=1
    • blocked by unrelated baseline import failure: Cannot find package '@openclaw/fs-safe/config' imported from src/infra/fs-safe-defaults.ts

Scope note

This covers the approved-followup association seam and stale-context suppression in the resumed agent prompt. If future reports show wrong bytes already inside the exact completion details, the lower-level runExecProcess/supervisor output callbacks need additional runtime diagnostics.

Changed files

  • src/agents/bash-tools.exec-approval-followup.test.ts (modified, +13/-2)
  • src/agents/bash-tools.exec-approval-followup.ts (modified, +15/-4)
  • src/agents/bash-tools.exec-host-gateway.test.ts (modified, +107/-0)
  • src/agents/bash-tools.exec-host-gateway.ts (modified, +1/-0)
  • src/agents/bash-tools.exec-host-node.ts (modified, +1/-0)
  • src/agents/bash-tools.exec-host-shared.ts (modified, +3/-0)

Code Example

ssh gx10-1 'cat /home/clawbot/runs/2026/05/2026-05-06T02-09-31Z_f9c09e.md'

---

ssh -o BatchMode=yes -o ConnectTimeout=10 gx10-1 'echo SSH_OK && hostname && whoami'

---

SSH_OK
gx10-1
clawbot

---

ssh gx10-1 'cat /home/clawbot/runs/2026/05/2026-05-06T02-09-31Z_f9c09e.md'
RAW_BUFFERClick to expand / collapse

Summary

After approving an exec request from a subagent, the command sometimes executes but the returned stdout/stderr is from an unrelated context instead of the approved command. This showed up with SSH reads from gx10-1.

Environment

  • OpenClaw: 2026.5.4
  • Gateway mode: local
  • Host: macOS
  • Affected subagent observed: localfirst-researcher

Expected behavior

When a subagent runs an approved command like:

ssh gx10-1 'cat /home/clawbot/runs/2026/05/2026-05-06T02-09-31Z_f9c09e.md'

The returned output should be the contents of that remote file.

Actual behavior

After approval, the returned output can be unrelated content from a different context/run (for example weather/stock benchmark traces), rather than the SSH command output.

Why this appears to be a routing bug, not SSH/auth

Control checks succeeded:

  1. Minimal SSH probe from LocalFirst worked:
ssh -o BatchMode=yes -o ConnectTimeout=10 gx10-1 'echo SSH_OK && hostname && whoami'

Returned:

SSH_OK
gx10-1
clawbot
  1. Direct SSH read from main/direct execution path also worked and returned the correct file contents.

So:

  • SSH connectivity works
  • host alias resolution works
  • auth/trust works
  • approval itself succeeds

The failure appears to be in approved exec result routing / output association.

Repro steps

  1. Ask a subagent to run:
ssh gx10-1 'cat /home/clawbot/runs/2026/05/2026-05-06T02-09-31Z_f9c09e.md'
  1. Approve the exec request
  2. Observe the returned output
  3. Intermittently, output is unrelated to the approved command

Additional note

This can make it look like approval or SSH is broken, but the stronger signal is that the wrong output stream is being attached to the approved command result.

Impact

  • Makes approved subagent exec unreliable
  • Can confuse users into thinking they approved the wrong command
  • Breaks trust in SSH/file inspection workflows

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

When a subagent runs an approved command like:

ssh gx10-1 'cat /home/clawbot/runs/2026/05/2026-05-06T02-09-31Z_f9c09e.md'

The returned output should be the contents of that remote file.

#configuration error#environment variable#network issue#logging issue#authentication issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix Approved exec command can return unrelated output in subagent context [1 pull requests, 1 comments, 2 participants]