Code Execution & Sandboxing

OpenClaw can do more than answer questions. It can run shell commands, inspect files, build software, and automate real work. That power is useful, but it also needs guardrails. This is where code execution rules and sandboxing matter.

What code execution means in OpenClaw

In practice, code execution usually happens through the exec tool. It can run shell commands in a workspace, capture output, and optionally keep long-running jobs alive in the background. For follow-up control, the process tool can read logs, send input, or terminate the task.

This is different from pure text generation. Once command execution is enabled, the agent can interact with the real environment, not just describe what should happen.

Why sandboxing exists

Shell access is powerful enough to help, and powerful enough to cause damage. A sandbox reduces the blast radius. Instead of letting every command touch the full machine, OpenClaw can restrict where commands run, what files they can access, whether they can use the network, and whether they can request elevated permissions.

Main protections

• Workspace isolation, so commands stay inside the intended project
• Limited filesystem access outside the allowed directory
• Optional network restrictions
• Approval gates for elevated commands
• Separate execution contexts for coding agents and sub-agents

Sandboxing is risk reduction, not magic

A sandbox does not make every command safe. If a command can still access your project files, it can delete or overwrite them. If network access is allowed, it can still send data outward. If you approve an elevated command, you are intentionally expanding what it can do.

The right mental model is simple: sandboxing buys containment, not immunity.

Common execution modes

Direct shell execution

Use direct execution for tasks like listing files, running tests, building a site, checking a process, or fetching command output. It is fastest when you already know the exact command you want.

Background jobs

Some commands take longer than a single response window. OpenClaw can start them with exec and then continue monitoring through process. This works well for builds, servers, long downloads, and agent-driven coding tasks.

Sub-agents and coding agents

For larger implementation work, use a sub-agent or ACP coding session instead of stuffing everything into one shell command. These flows give the agent room to inspect the codebase, make edits, and verify results without turning the main session into a wall of terminal output.

When approvals matter

Approval should appear whenever a command is sensitive enough that a human should decide. Good examples include:

• Commands that need elevated permissions
• Actions that modify system packages or host services
• Destructive operations like mass deletion or database resets
• Anything that touches secrets, deployment targets, or production systems

If approval is required, the safest habit is to inspect the exact command, not the summary around it.

Best practices for safe execution

• Prefer the smallest command that solves the problem. Smaller scope means fewer surprises.
• Keep work inside the workspace. Avoid broad commands that traverse the whole machine.
• Review destructive flags carefully. rm -rf, force pushes, and bulk rewrites deserve extra caution.
• Use background monitoring for long tasks. Start once, then poll status instead of rerunning commands repeatedly.
• Escalate only when necessary. If a normal command works, do not request elevated access just because it is available.

exec vs coding agent

Typical mistakes

Trusting generated commands blindly

Even a good agent can make a bad call. Review commands that write, delete, install, deploy, or change permissions.

Running broad commands from the wrong directory

A safe command in one workspace can be destructive in another. Always verify the working directory when the command modifies files.

Using shell execution for work that needs a real workflow

If a task involves exploration, repeated edits, and verification, a coding agent or sub-agent usually beats a giant chained shell command.

Troubleshooting execution problems

• Command fails immediately: Check the working directory, binary availability, and quoting.
• No permission: The sandbox may block the action, or the command may need explicit approval.
• Process seems stuck: Poll logs with process before assuming failure.
• Command works locally but not in OpenClaw: Compare environment variables, sandbox rules, and network access.

Security mindset

The safest OpenClaw setups treat execution as a tool, not a default reflex. Use it when it helps. Keep scope narrow. Let approvals catch dangerous edges. And when the task is bigger than one command, reach for the right execution model instead of forcing it.