Routing and Securing Agent Execution

We have all been there: you want your AI agent to actually do something useful, but it is stuck in a restricted container. Or, on the flip side, you worry that giving an agent access to your machine might lead to a “rm -rf /” disaster. Balancing power and safety is one of the hardest parts of building agentic workflows.

I want to show you how we are solving this with a new execution refactor. We are moving away from a “one-size-fits-all” sandbox and introducing a way to route commands to different hosts while keeping security tight with allowlists and manual approvals.

What You’ll Need

• OpenClaw Gateway
• Node runner (for remote execution via Bridge)
• macOS app (optional, if you want a UI for command approvals)

Quick Start

The fastest way to change how your agent runs code is using the /exec slash command or updating your global config. By default, everything stays safe in a sandbox.

1. Choose your host

You can tell the agent where to run commands by setting exec.host:

• sandbox: Runs in a Docker container (the default).
• gateway: Runs on the machine where the gateway is hosted.
• node: Runs on a specific connected node runner.

2. Set your security policy

Decide how much you trust the agent with exec.security:

• deny: Blocks all execution.
• allowlist: Only runs commands that match your approved patterns.
• full: Allows everything (use this carefully).

3. Configure “Ask” behavior

You can control when the system asks for your permission using exec.ask:

• on-miss: Only asks if the command isn’t in your allowlist.
• always: Asks for every single command.
• off: Never asks.

4. Try the shortcut

If you need to move quickly, I recommend the /elevated command. It is a shortcut to get things done on the gateway host.

# Turn on full access for the gateway host
/elevated on

# Turn it off to go back to safe defaults
/elevated off

How it Works

When an agent tries to run a tool, the system checks the hierarchy: it looks at the tool parameters first, then the agent’s specific overrides, and finally the global defaults.

If the agent targets a gateway or node, it looks at a local file at ~/.openclaw/exec-approvals.json. This file acts as the brain for security on that specific machine. Here is what that file looks like:

{
  "version": 1,
  "socket": {
    "path": "~/.openclaw/exec-approvals.sock",
    "token": "base64-opaque-token"
  },
  "defaults": {
    "security": "deny",
    "ask": "on-miss",
    "askFallback": "deny"
  },
  "agents": {
    "agent-id-1": {
      "security": "allowlist",
      "ask": "on-miss",
      "allowlist": [
        {
          "pattern": "~/Projects/**/bin/rg",
          "lastUsedAt": 0,
          "lastUsedCommand": "rg -n TODO",
          "lastResolvedPath": "/Users/user/Projects/.../bin/rg"
        }
      ]
    }
  }
}

Troubleshooting

No UI for approvals

If you are running a headless setup and the system needs to “ask” for permission but cannot find the macOS app UI, it uses the askFallback setting. If this is set to deny, your commands will fail. I suggest checking your exec-approvals.json to ensure askFallback matches your headless workflow.

Ambiguous node selection

When you set exec.host = node, the agent might not know which node to pick if you have multiple runners connected. You can fix this by being explicit:

• Use exec.node to bind the agent to a specific nodeId or displayName.
• If you don’t bind a node, the agent might target any available node that your policy allows.

Truncated output

To keep things fast, we cap command output at 200k. If a command produces more than that, you will see a ... (truncated) message. We always keep the last 20k of the output so you can see the final logs or errors.

For more help, talk to our AI Setup Assistant.

What’s Next

• Exec tool
• Exec approvals
• Nodes
• Elevated mode