Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

OpenClaw: 2026.6.10
Exec host: gateway
Effective policy: security=allowlist, ask=on-miss
Exec security: allowlist
Exec ask: on-miss

Observed from both main agent and subagent. Plain openclaw --version behaves normally; openclaw --version 2>&1 hides Allow Always with misleading policy text.

Discord Support Discussion

Steps to reproduce

1. Ask main agent or subagent to run: openclaw --version
2. Observe Allow Always is available / command can run normally.
3. Ask main agent or subagent to run: openclaw --version 2>&1
4. Observe Allow Always is unavailable and the prompt says:
   “The effective approval policy requires approval every time, so Allow Always is unavailable.”

Expected behavior

If Allow Always is unavailable because shell redirection makes the command non-persistable/one-shot, the prompt should say that. It should not imply the effective policy is ask=always when openclaw approvals get --gateway shows ask=on-miss.

Actual behavior

Actual behavior

When the requested command includes shell redirection, for example:

openclaw --version 2>&1

OpenClaw shows an exec approval prompt, but Allow Always is unavailable. The prompt explains this by saying:

The effective approval policy requires approval every time, so Allow Always is unavailable.

This happens even though the effective gateway exec policy is security=allowlist and ask=on-miss, confirmed by openclaw approvals get --gateway / effective policy output.

The same command without redirection:

openclaw --version

does not show the misleading behavior and can run normally / offers the expected reusable approval behavior. The behavior is the same from the main agent and from a subagent, so the trigger appears to be the redirected command shape rather than subagent routing.

OpenClaw version

2026.6.10

Operating system

macOS 15.7.7

Install method

npm global

Model

openrouter/deepseek/deepseek-v4-flash

Provider / routing chain

OpenClaw -> OpenRouter

Additional provider/model setup details

Not relevant / not model-specific. Reproduced with exec approval prompts via the gateway host. The behavior appears tied to command shape (2>&1 redirection), not the provider or model.

Logs, screenshots, and evidence

Impact and severity

Affected users/systems/channels: Users using gateway exec approvals, including Telegram approval prompts, for commands that include shell redirection such as 2>&1. Observed from both the main agent and a subagent.

Severity: Annoying / workflow friction, not currently observed as data loss or a full workflow block. The command can still be approved once, but Allow Always is unavailable and the prompt gives a misleading reason.

Frequency: Always for the observed redirected command shape (openclaw --version 2>&1) in the tested setup. Not reproduced for the plain command (openclaw --version).

Consequence: Users may have to repeatedly approve redirected commands and may misdiagnose their approval policy as ask=always even when effective policy is ask=on-miss. This adds troubleshooting time and makes the approval UI harder to trust.

Additional information

Asking agent main to run openclaw --version:

Asking agent main to run openclaw --version 2>&1:

Asking agent main to run a subagent to run openclaw --version:

Asking agent main to run a subagent to run openclaw --version 2>&1: