openclaw - 💡(How to fix) Fix [Feature]: Forward exec-approvals.json allowlist to claude-cli backend sessions

Product / Version

OpenClaw 2026.4.15 (041266a) — stable channel

Summary

When an agent uses claude-cli as its primary model provider, exec calls are handled internally by Claude Code. OpenClaw's exec-approvals.json allowlist and tools.exec.security: "allowlist" setting are never consulted. This creates two enforcement layers that don't compose:

1. OpenClaw native exec (codex/embedded runners) → checks exec-approvals.json → enforces allowlist
2. Claude Code internal exec (claude-cli runner) → uses Claude Code's own --permission-mode → ignores exec-approvals.json

An operator who sets security: "allowlist" for an agent using claude-cli gets inconsistent enforcement: allowed commands may stall with approval prompts (Claude Code doesn't know about the allowlist), while blocked commands may silently execute (Claude Code's auto mode trusts some system binaries).

Expected Behavior

When tools.exec.security: "allowlist" is set for an agent and that agent uses claude-cli as its backend, OpenClaw should forward the exec policy to the CLI backend so that:

• Commands matching the agent's allowlist are permitted
• Commands not in the allowlist are denied
• The enforcement is consistent regardless of which runner handles the session

Actual Behavior

With --permission-mode auto:

• Some system binaries (/usr/bin/python3, ls, date) auto-execute without consulting the allowlist
• Some binaries (git, openclaw, bash, curl) produce approval prompts in Claude Code, even if they're in the OpenClaw allowlist
• The operator cannot achieve consistent exec policy across all runners

Impact

• Agents using claude-cli cannot be meaningfully placed on security: "allowlist" — the setting has no effect on their exec path
• Multi-agent fleets with mixed runners have inconsistent security posture
• The only reliable options for claude-cli agents are security: "full" (accept the risk) or not using claude-cli (lose the model)

Reproduction

1. Set an agent (e.g., nikola) to security: "allowlist" with a specific per-agent allowlist (e.g., git, openclaw, claude)
2. Set the agent's primary model to claude-cli/claude-opus-4-7
3. Set --permission-mode auto in agents.defaults.cliBackends.claude-cli.args
4. Send the agent a message: "Run: python3 --version"
5. Observe: python3 executes (returns Python 3.9.6) despite NOT being in the agent's allowlist
6. Send: "Run: git --version"
7. Observe: git produces a Claude Code approval prompt despite BEING in the agent's allowlist

With a codex-runner agent (same allowlist, same commands), python3 is correctly denied (exec denied: allowlist miss) and git correctly executes.

Evidence

Full investigation documented internally:

• Sandbox tested with nikola on allowlist + claude-cli/claude-opus-4-7
• Logs show cli exec: provider=claude-cli model=opus — exec goes through Claude Code, not OpenClaw
• No exec denied: allowlist miss entries appear for claude-cli sessions
• Same tests with doubtfire/sentry (codex runners) show clean exec denied: allowlist miss enforcement

Current Workaround

Keep agents using claude-cli on security: "full" and rely on:

• Claude Code auto mode (partial enforcement — prompts on bash, curl, git)
• AGENTS.md operational guardrails
• Agent workspace scoping

Why Not Fixed in 2026.4.15

The 2026.4.15 changelog contains no changes to exec policy forwarding for CLI backends. The Codex/CLI: keep resumed codex exec resume runs on the safe non-interactive path (#67666) fix is about the codex CLI's own bypass flag, not about OpenClaw forwarding its exec policy.

Possible Approaches

1. Forward allowlist to CLI backend — OpenClaw could intercept exec tool calls from the CLI backend and check them against exec-approvals.json before allowing Claude Code to execute
2. Pass allowlist as CLI args — OpenClaw could pass the agent's allowed binaries as Claude Code CLI flags (e.g., --allowed-tools)
3. Pre-exec hook — OpenClaw could add a pre-exec hook that validates the command before the CLI backend runs it

Recommended Priority

MEDIUM — affects multi-agent security posture for operators using mixed runners.

Draft prepared for GitHub filing. No real secrets included.