openclaw - 💡(How to fix) Fix [Bug]: exec tool silently corrupts 2>&1 / 2>/dev/null shell redirect arguments

Bug type

Behavior bug

Impact

Blocks the use of 2>&1 / 2>/dev/null shell redirects with the exec tool, and corrupts --json field lists containing 2>&1 patterns. This affects any workflow that inspects gh command results (and likely other CLI tools) through the OpenClaw exec tool.

Summary

When using the OpenClaw exec tool, arguments containing 2>&1 or 2>/dev/null (shell redirect syntax where 2 and > are separated by whitespace) get their whitespace silently stripped during OpenClaw's argument tokenization, causing them to be passed as a single merged token to the underlying shell/process. This corrupts commands in ways that are hard to diagnose.

Environment

• OpenClaw version: 2026.5.27 (installed via Homebrew, node_modules path /opt/homebrew/lib/node_modules/openclaw)
• OS: macOS Darwin 25.5.0 (arm64)
• Node.js: v26.0.0
• Shell: zsh (login shell)

Steps to reproduce

Reproduction 1 — gh search issues --state open2>&1:

# Command intended (with stderr redirected):
gh search issues --state open --repo openclaw/openclaw -L5

# Command actually executed (tokenization bug):
gh search issues --state open2>&1 --repo openclaw/openclaw -L5
# Result: "invalid argument 'open2' for '--state' flag"

Reproduction 2 — --json title,state2>&1:

# Intended:
gh search issues "test" --repo openclaw/openclaw -L5 --json title,state

# Actually executed (gh receives field name "state2"):
gh search issues "test" --repo openclaw/openclaw -L5 --json title,state2>&1
# Result: "Unknown JSON field: 'state2'"

Reproduction 3 — Any 2>&1 in command body:

# Intended: check if a process is running and capture both stdout and stderr
ps aux 2>&1 | grep someprocess

# Actually executed:
ps aux 2>&1 | grep someprocess
# Result: "ps: 2>&1: command not found" — the entire string "2>&1" is treated as one arg

Expected behavior

• Arguments passed to the exec tool should be passed to the underlying shell/process exactly as provided, preserving whitespace in redirect syntax.
• Commands using 2>&1 / 2>/dev/null redirects should work normally.

Actual behavior

Whitespace between 2 and > in redirect syntax is silently dropped, causing:

1. open2>&1 is treated as a single malformed argument instead of open + 2>&1
2. --json title,state2>&1 is parsed as JSON field state2 instead of state + 2>&1
3. Any command using command 2>&1 gets "command": command not found because 2>&1 is passed as the first argument to the command

Root cause hypothesis

OpenClaw's exec tool argument tokenization splits on whitespace but appears to treat 2>&1 as a special sequence, or concatenates tokens in a way that strips whitespace between 2 and >. The tokenization logic seems to merge what should be two adjacent tokens (2 and >&1 / 2>&1) into a single token.

The bug does not appear when --state open is used without any following redirect — meaning the bug is triggered specifically when 2 and >&1 are separated by whitespace.

Impact assessment

• Severity: Medium — blocks stderr redirection for any CLI tool invoked through exec
• Workaround: Use --json without 2>&1, or use curl with GitHub REST API instead of gh CLI
• Affected commands: Any tool invoked via exec that uses 2>&1 / 2>/dev/null / 1>&2 redirect syntax

Additional context

This bug was discovered while investigating a separate webchat UI issue (GitHub issues #87875, #87649, #87387). While running gh search issues --state open2>&1 to search for related OpenClaw bugs, the command failed with the error shown above.

The workaround is to either:

1. Omit 2>&1 from the command (works for gh since it outputs to stdout by default)
2. Use curl with the GitHub REST API + python3 parsing instead of gh CLI

Related issues about the exec tool:

• #48780: "[Bug]: [Windows] exec() and read() commands corrupted with </arg_value>> suffix" — similar class of argument corruption
• #53408: "[Bug]: Write/exec tool parameters silently dropped after long conversations"
• #70033: "Tool calls emit empty arguments {} when content parameter is large (write/exec)"