A Pre-Deploy Checklist for OpenClaw: Isolation, Keys, Skills and Rollback

I won't put OpenClaw's first install on my main computer

OpenClaw can connect the model to files, the shell, the browser, Skills, message channels and a long-running Gateway. If the first install uses your main account, home directory and a real Bot, any config error touches personal files, credentials and external messages all at once.

So this article's starting point isn't the install command — it's an environment you can delete, a test directory with no secrets, and four kinds of credential that can be revoked separately.

This round didn't complete a full isolated install in a new VM. The commands, config fields and security model below come from the current official Install, Sandbox, Security and Audit docs; they don't pose as a local run record. An actual deploy still has to add your own version, logs, ports and boundary tests.

This isn't over-caution. An Agent that can take actions must have its security proven by "what it can't do."

Where the risk begins

An ordinary web chat usually only handles what you actively submit.

OpenClaw can connect the model to:

• Local files.
• Shell commands.
• The browser.
• Skills and plugins.
• Message channels like Telegram.
• API keys and OAuth credentials.
• A long-running Gateway.

The model can not only answer but also take actions. A bad prompt, a malicious web page or an over-permissioned Skill can amplify a problem from a bit of wrong text into a file, account or system change.

The security goal isn't to trust the model to never err — it's to make one error only affect a small range.

OpenClaw's three boundaries

The Gateway boundary

The Gateway handles sessions, tools and channel connections. Even with tools in the Sandbox, the Gateway still runs in the host environment.

So "turning on the Sandbox" can't automatically prove the whole system is fully isolated.

The Tool boundary

The official Sandbox docs explain that tools like exec, read, write, edit, apply_patch and process can run on an isolated backend.

The Sandbox can significantly reduce the blast radius, but the docs are also explicit: it's not a perfect security boundary.

The Credential boundary

The model API key, the message-channel token, the Gateway key and the system login credentials aren't the same kind of secret.

They should have different permissions, different storage and different revocation paths. Don't, for convenience, write every credential into one config file and keep it long-term.

Don't put the first deploy on a bare main computer

A steadier starting point:

• A deletable VM.
• A separate low-privilege system user.
• A test device with no personal documents.
• A container with a limited set of mounted directories.
• A test channel not connected to production accounts.

Put only one sample directory with no sensitive info in the isolated environment. After confirming what OpenClaw can do, add necessary capabilities one by one.

Don't mount your whole home directory, SSH directory, browser profiles, cloud drive and real projects at the start.

Ten checks before installing

1. Record the current system and chip architecture.
2. Confirm the environment can be deleted wholesale or snapshot-restored.
3. Don't use a long-term API key from your main account.
4. Don't connect a real Telegram group and client messages.
5. Prepare a separate test directory.
6. Close unnecessary public entrances.
7. Make clear who can message the Agent.
8. Record the ports open before install.
9. Prepare an uninstall and credential-revocation list.
10. Save the official-docs verification date.

As of 2026-08-11, the Node support range listed on the official install page changes fairly fast; re-check it on the day you install — don't copy a version from an old tutorial.

First look at what the install script plans to do

The official docs provide macOS, Linux, WSL and Windows install methods. The script can auto-prepare the run environment and start onboarding.

Handing a remote script straight to the shell is convenient, and it also means you trust what the current URL returns. The official installer supports a dry run, so you can view the plan first:

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --dry-run

If you want to install but not run onboarding yet, use the official no-onboard option:

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --no-onboard

The above is the official command structure, not this round's run record. When installing, re-check the official page.

After installing, verify three levels first

The official basic checks include:

openclaw --version
openclaw doctor
openclaw gateway status

They prove, respectively:

• The CLI can be found.
• The config accepts a diagnosis.
• The Gateway has an observable status.

This still isn't the same as the model, Sandbox, message channels and all Skills being safe.

The first run should keep verifying:

• Which environment tools actually run in.
• Whether it can read outside the test directory.
• Whether writes only happen in allowed directories.
• Whether the network can reach unauthorized targets.
• Which account and session messages come from.
• Whether logs print credentials.

A recommended Sandbox starting point

The official config allows controlling mode, scope and workspaceAccess.

For a first test, a conservative approach is:

{
  "agents": {
    "defaults": {
      "sandbox": {
        "mode": "all",
        "scope": "agent",
        "workspaceAccess": "none"
      }
    }
  }
}

This config expresses:

• All relevant sessions use the Sandbox.
• Different Agents don't share one Sandbox.
• The Agent workspace isn't mounted into the Sandbox by default.

If a task must read the project, start from read-only:

workspaceAccess: ro

Consider rw only when editing is clearly needed. Every widening of permission should add a matching acceptance.

The config keys may change with versions; go by the current official docs before use.

Why the Sandbox still isn't enough

Even with tools running in a container, still check:

• Which host directories the container mounts.
• Whether the Docker Socket is mounted.
• Which domains the network can reach.
• Whether the Gateway is exposed to the public internet.
• Whether the browser shares a real login state.
• Whether credentials enter the container via environment variables.
• Whether multiple users share one session.

The official security docs note that OpenClaw's default trust model is closer to a single-operator personal assistant; one instance shouldn't be treated directly as an untrusted multi-user isolation platform.

For multiple people, consider separate Gateways, separate OS users or separate hosts — not just different chat windows.

Review Skills like a code dependency

A Skill isn't a harmless note. It may require:

• Running commands.
• Installing packages.
• Reading files.
• Calling external APIs.
• Using the browser.
• Writing config.
• Triggering a message or a publish.

Before enabling, check at least:

1. The source repo and maintainer.
2. The last update time.
3. The install script.
4. The requested file scope.
5. The requested network targets.
6. The environment variables it reads.
7. Whether it holds external actions.
8. What it leaves after uninstall.

A Skill you don't use, just don't install. One installed but not needed for now — disabling is more reliable than "trusting it won't be called."

Give channels like Telegram a separate test identity

A message channel brings external input into the Agent, and also sends the Agent's output into an external platform.

When testing:

• Use a separate Bot.
• Don't join real groups.
• Allow only your own account.
• Don't reuse a personal Bot token.
• Record the pairing and authorization.
• Confirm the token-revocation path in advance.
• Don't let a message directly trigger a high-risk command.

"Only I know the bot's name" isn't access control.

Split credentials into at least four kinds

Model credentials: decide which models can be called and how much cost is incurred.

Gateway credentials: decide who can manage the service.

Message-channel credentials: decide who can send and receive as the Bot.

External-tool credentials: GitHub, email, cloud services, and so on.

When one kind leaks, you should be able to revoke it alone, without rebuilding the whole environment.

Don't put full values in logs, screenshots or an article. Examples use only obviously invalid placeholders.

Run the Security Audit

The official tool provides a read-only security review and a deeper probe:

openclaw security audit
openclaw security audit --deep

The ordinary review mainly checks cold config and the filesystem; deep mode adds Gateway- and plugin-related probing.

Don't run an auto-fix without understanding it. Save the report first, confirm item by item what it plans to change, then decide whether to use fix.

A passing audit is only evidence for the current config; it doesn't mean a new Skill and new channel installed later stay safe.

Verify the boundary with five malicious tests

In the test directory, prepare no sensitive data, and observe whether OpenClaw can:

1. Read a file outside the test directory.
2. Write to an unauthorized path.
3. Reach an unallowed domain.
4. Send a command from another account.
5. Print a test key in a log.

The expected result should be refusal, a request for approval, or a clear failure — not quietly completing.

Tests use fake marker text, not real passwords and production keys.

Write the rollback plan before installing

The rollback includes at least:

• Stop the Gateway.
• Delete the startup service.
• Uninstall OpenClaw.
• Delete or archive the test config.
• Revoke the model key.
• Revoke the Bot token.
• Delete the test VM or container.
• Check that ports no longer listen.
• Check there are no leftover background processes.

The official install docs provide update, migration and uninstall entrances. Don't assume the service has stopped just because you deleted one CLI file.

Before connecting real accounts, I run through this again

You need at least this evidence:

• The version and install source are recorded.
• The Gateway listens only where expected.
• The Sandbox is actually enabled.
• Workspace permission starts from none or ro.
• Nothing outside the test directory can be read or written.
• Only reviewed Skills are installed.
• The message channel allows only the test identity.
• Credentials can be revoked separately.
• The Security Audit report is saved.
• The uninstall and recovery paths actually work.

Once the test environment clearly refuses out-of-bounds reads, out-of-bounds writes and commands from unknown accounts, connect the first real capability. Don't let OpenClaw take over your main computer first and then expect a later permission rule to clean up the scene for you.