openclaw - 💡(How to fix) Fix [Feature]: Expose exec/process over claude-cli bundle MCP behind an explicit experimental opt-in, preserving OpenClaw exec approvals

Summary

Allow the bundled claude-cli loopback MCP server to optionally expose the exec (and process) tools, gated behind an explicit dangerous/experimental config flag, so agents on the claude-cli runtime can run remote-node commands through OpenClaw's existing exec-approval flow (host=node, allowlist, ask, approval cards).

Problem to solve

On the claude-cli agent runtime, exec and process are hardcoded out of the loopback MCP tool list (NATIVE_TOOL_EXCLUDE in src/gateway/mcp-http.runtime.ts: ["read","write","edit","apply_patch","exec","process"]). As a result, an agent running on claude-cli has no path to OpenClaw's exec host=node approval flow:

• Claude Code's native Bash tool is denied by the permission bridge when exec policy is security:"allowlist" / ask:"always" (correct — we don't want to bypass approvals).
• There is no mcp__openclaw__exec tool to fall back to, because exec is excluded from the bundled MCP list.

The net effect: with a claude-cli model, you can EITHER have a Claude model OR have remote-node exec approval cards, but not both. Forcing Claude off native Bash (via --disallowedTools Bash --allowedTools mcp__openclaw__*) just leaves it with no exec tool at all — it narrates "I can't run commands" without ever invoking exec.

The only way to get approval cards today is to use the embedded runtime, which means giving up the claude-cli model choice for that agent. For users who specifically want a Claude (claude-cli) model AND OpenClaw's audited approval-card flow for remote node execution, there is currently no supported route.

Proposed solution

Add an explicit, opt-in config flag (clearly labelled experimental/dangerous) that allows exec and/or process to be included in the claude-cli bundle MCP tool list, e.g.:

agents.defaults.cliBackends.claude-cli.experimentalExposeExecOverMcp: true

When enabled, mcp__openclaw__exec (and optionally mcp__openclaw__process) would be served to Claude Code, and crucially would route through OpenClaw's existing exec-approval machinery — honouring tools.exec.host, security (allowlist), ask, and emitting the normal approval cards. The point is NOT to bypass approvals (bypassPermissions / YOLO already does that); it's to let the claude-cli runtime reach the SAME approval-gated exec path the embedded runtime uses.

Default off. Documented as experimental. Approval/audit behaviour identical to embedded-runtime exec so there's no second, weaker security path to maintain.

Alternatives considered

1. Custom external MCP server exposing a node-exec tool that calls the Gateway exec path. Technically possible (claude-cli merges user --mcp-config) but means the user hand-maintains a security-critical bridge outside OpenClaw — exactly the boundary OpenClaw exists to manage. High risk of introducing the unrestricted-exec hole the approval flow is meant to prevent.

2. Locally patch OpenClaw to remove exec/process from NATIVE_TOOL_EXCLUDE. Works, but forks the gateway, must be re-applied on every update (the gateway updates frequently), and isn't maintainer-reviewed/supportable.

3. Use cron (which IS exposed over MCP) as an exec tunnel. Wrong shape — breaks approval/audit semantics, confuses the model of what ran and when.

4. Use the embedded runtime instead of claude-cli for the node-touching agent. This is the current supported workaround and works, but forces giving up the claude-cli model choice — which is the whole reason for the request.

All four either compromise the security boundary, create maintenance burden, or defeat the purpose. A first-class opt-in flag is the clean path.

Impact

• Affected users/systems/channels: Anyone using the claude-cli agent runtime (Claude models via subscription/CLI) who also wants OpenClaw remote-node exec with approval cards. Any channel (Discord/Telegram/Slack) + remote node (headless VPS, home server) combination.

• Severity: Blocks workflow. There is no supported way to combine claude-cli + remote-node approval cards. The user must choose one and abandon the other.

• Frequency: Always — it's a hard architectural exclusion, reproducible on every version checked (5.27, 5.28-beta.4, 5.29-alpha.1, main).

• Consequence: Users wanting Claude-model quality for an agent that manages a remote box must either (a) drop to a non-Claude API model to keep the approval cards, or (b) disable approvals entirely (security risk on internet-facing nodes), or (c) build/maintain unsupported custom security plumbing. For a safety-conscious setup on an internet-facing VPS, the only safe supported option is giving up the Claude model.

Evidence/examples

Confirmed by Discord bot (Krill) across v2026.5.27, v2026.5.28-beta.4, v2026.5.29-alpha.1, and current origin/main: exec and process are hardcoded in NATIVE_TOOL_EXCLUDE in src/gateway/mcp-http.runtime.ts, passed as excludeToolNames when the loopback MCP tool cache resolves tools. No config key exists around it.

Observed behaviour on 2026.5.27, claude-cli runtime + claude-haiku-4-5, tools.exec = {host:"node", security:"allowlist", ask:"always"}, channels.discord.execApprovals = {enabled:true, target:"dm", approvers:[...]}:

• With default args: model uses Claude Code native Bash → "claude live control_request: subtype=can_use_tool tool=Bash decision=deny" (permission bridge correctly denies since policy isn't YOLO). No approval card, command never runs.
• After setting cliBackends.claude-cli args with --disallowedTools Bash --allowedTools mcp__openclaw__*: Bash is gone, but the model now invokes no exec tool at all (no can_use_tool, no mcp__openclaw__exec, no exec.approval, no SYSTEM_RUN_DENIED in logs). It just replies that it can't run commands and approvals "aren't working" — because mcp__openclaw__exec does not exist to be called.

Confirmed: openclaw-tools-serve MCP exposes only cron; channel MCP exposes conversations + approval helpers, not an exec runner. So no bundled MCP path to exec exists for claude-cli.

Additional information

Embedded-runtime exec approval cards work correctly (verified on this setup with an API model on 2026.5.12 — full flow: Discord card → Allow → command runs on remote node). The request is purely to make that same approval-gated exec path reachable from the claude-cli runtime behind an explicit experimental opt-in.

Strong preference that any exposed exec over claude-cli MCP route through the EXISTING approval machinery (not a parallel/weaker path), so there's only one security boundary to reason about. Default-off and clearly labelled experimental is expected and desired.