So You Installed OpenClaw on a Digital Ocean Droplet. Now what?

Before you do anything else, it helps to understand how users work on this server.

OpenClaw doesn’t run as root. It runs under a dedicated system user called openclaw. That user was created during installation specifically so the AI runtime doesn’t have root-level access to your system.

The split works like this:

• root handles system configuration – things like environment variables, execution policies, and service management.
• openclaw runs the actual tools and skills. This is the user you’ll switch to when installing or testing skills.
• openclaw can’t edit the environment file (/opt/openclaw.env). That’s on purpose.

You’ll be switching between these two users throughout this guide. When something needs to be done as a specific user, it’ll be called out.

Skills teach OpenClaw how to use tools. Some are self-contained like humanizer (just a skill file), others like gog (Google Workspace) also need a binary installed separately.

SSH into your droplet and switch to the openclaw user:

ssh root@DROPLET_IP
su - openclaw

Install a skill from ClawHub:

npx clawhub@latest install humanizer

That’s it. Humanizer is a skill-only install - no binary needed.

For skills that need a binary (like gog for Google Workspace), you also install it via Homebrew:

npx clawhub@latest install gog  # skill file from ClawHub
/home/openclaw/homebrew/bin/brew install steipete/tap/gogcli  # binary via Homebrew

Many skills need API keys or credentials to work (e.g., TWITTER_AUTH_TOKEN for Bird, GOG_ACCOUNT for Google Workspace).

These are stored as environment variables in:

/opt/openclaw.env

You can’t edit this file as the openclaw user. You’ll get a permission denied error.

That’s by design. The openclaw user isn’t allowed to change its own configuration. If the runtime could rewrite its own environment variables, a misbehaving skill could change API keys, redirect outputs, or mess with settings you didn’t intend. So that file is owned by root, and only root can touch it.

To edit it, first get back to root:

exit

Then open the file:

nano /opt/openclaw.env

Add whatever your skill needs:

TWITTER_AUTH_TOKEN=your_key_here
TWITTER_CT0=value

Save and exit.

The idea is straightforward: the runtime user can’t rewrite its own environment variables or credentials. A misbehaving skill can’t swap out API keys or redirect outputs. Root stays in control of that file.

After you change this file, you need to restart the service. The changes won’t take effect until you do.

This is the section that would have saved me a lot of time early on.

If you installed a skill and it just sits there doing nothing – no errors, no output, nothing – it’s probably an execution policy issue. These control how OpenClaw is allowed to run things on the system.

Run these as root:

/opt/openclaw-cli.sh config set tools.exec.host gateway
/opt/openclaw-cli.sh config set tools.exec.ask off
/opt/openclaw-cli.sh config set tools.exec.security full

Here’s what each one does.

tools.exec.host gateway

This tells OpenClaw to route all execution through its gateway process.

On a VPS, there’s no terminal window open. There’s no shell session sitting there waiting. When OpenClaw needs to run a command, it needs somewhere to run it. The gateway is that somewhere – a persistent process that receives commands, executes them, logs what happened, and returns results. It works even when no one is SSH’d in.

Without this, OpenClaw tries to execute things in a context that doesn’t exist on a headless server. Commands will either fail or hang. On a VPS, you need this.

tools.exec.ask off

By default, OpenClaw may pause and ask for approval before running certain tools – a “are you sure?” type prompt.

On a local machine, that’s fine. You see the prompt, you approve it, everything continues. On a VPS, there’s no one sitting there to approve anything. The command just hangs, waiting for input that’s never coming.

Turning this off means commands run automatically without waiting for approval. That’s required if you want things like Telegram triggers or cron jobs to work.

The tradeoff is that you’re removing a safety layer. You’re trusting that the skills you installed will behave correctly.

tools.exec.security full

This gives OpenClaw the highest execution tier available within its own sandbox.

It does not give it root access. The openclaw user still can’t touch system files, can’t change its own config, and can’t escalate privileges. Everything from the “Set Enviornment Variables Must be Done as Root” section still holds.

What it does is loosen restrictions inside the sandbox. By default, OpenClaw runs in a fairly locked-down mode where it can’t do things like make network calls, write to temp directories, or run shell commands. That’s safe, but it means a lot of skills just won’t work.

The frustrating part is that when a skill gets blocked by a lower security tier, it often fails silently. No error message. No warning. The skill just does nothing. If you’ve installed something and it seems to be ignored, this is likely why.

Security Implications

When you combine tools.exec.ask off with tools.exec.security full, you’re enabling automated execution with minimal internal restrictions.

That’s the right setup when:

• The droplet is dedicated to OpenClaw
• You control what skills are installed
• Gateway access is secured
• Telegram access (if you’re using it) is restricted to you
• You understand what’s allowed to run

If you’re sharing this server with other things or other people, think carefully before doing this. These settings assume a dedicated, single-purpose setup.

Checking Current Values

To verify what the execution policies are currently set to, run these as root:

/opt/openclaw-cli.sh config get tools.exec.host
/opt/openclaw-cli.sh config get tools.exec.ask
/opt/openclaw-cli.sh config get tools.exec.security

Or to see all execution-related settings at once:

/opt/openclaw-cli.sh config get tools

This results in

{
  "exec": {
    "host": "gateway",
    "security": "full",
    "ask": "off"
  }
}

You’re looking for: host set to gateway, ask set to off, and security set to full. If any of those are different, that’s likely why a skill isn’t running.

Anytime you change environment variables or execution policies, you need to restart the service. None of your changes take effect until you do.

This must be done as root:

systemctl restart openclaw

This reloads everything – the env file, execution policies, installed skills, and runtime configuration.

If something isn’t working and you’ve checked everything else, make sure you actually restarted the service. It’s easy to forget.

If you’ve followed the steps above, you’ve already seen this in practice: some things require root, some things require openclaw, and those boundaries are enforced. Here’s the full picture in one place.

root owns the system. It controls configuration, manages the service, and sets execution policies. It’s the only user that can edit /opt/openclaw.env or run the config CLI.

openclaw is the runtime user. It runs skills, installs packages via Homebrew, and does the actual work. But it can’t change how it’s configured. It can’t rewrite its env file. It can’t change execution policies. That’s the whole point. It can change config settings via openclaw config set, but it can’t edit the environment file (/opt/openclaw.env) - that’s owned by root.

/opt/openclaw.env is the configuration file. Owned by root, read by the service at startup. The openclaw user can read the values at runtime but can’t modify the file.

Execution policies control what the openclaw user is actually allowed to do inside its sandbox. Set by root, enforced by the gateway.

This model exists so that:

• The AI runtime can’t modify its own behavior
• A buggy or misbehaving skill can’t corrupt the configuration
• Nothing escalates to root without you explicitly setting it up
• Automated changes don’t happen unless you’ve opted into them

OpenClaw’s runtime environment lives inside a Docker container. If you ever want to look at what’s actually in the sandbox – the configuration files, identity files, tools, and other runtime assets – you can connect to it directly.

This needs to be done as the openclaw user. If you’re currently root, switch first:

su - openclaw

Then find the container ID:

docker ps -a

You’ll see something like this:

CONTAINER ID   IMAGE                                COMMAND            CREATED       STATUS       NAMES
b4e688551a4e   openclaw-sandbox:bookworm-slim   "sleep infinity"   2 days ago    Up 2 days    openclaw-sbx-agent-main-0d71ad7a

Then connect to it:

docker exec -it <CONTAINER_ID> /bin/bash

Once inside, the sandbox root is /workspace:

ls /workspace

AGENTS.md  BOOTSTRAP.md  HEARTBEAT.md  IDENTITY.md  SOUL.md  TOOLS.md  USER.md  media  memory

These are the files that define how OpenClaw behaves – its identity, available tools, agent configurations, and so on. This is useful for debugging or just understanding what the runtime actually sees when it’s running.

You’re viewing these as read-only exploration. The sandbox is the runtime’s world – changes to these files should be made through the proper configuration paths, not by editing them directly inside the container.

Q: My skill installed but isn’t doing anything

Check these in order:

1. Are the required environment variables in /opt/openclaw.env?
2. Are the execution policies set correctly? Run /opt/openclaw-cli.sh config list | grep tools.exec as root to verify.
3. Did you restart the service after making changes? systemctl restart openclaw as root.

Q: I get “permission denied” when editing /opt/openclaw.env

That’s expected. You’re probably logged in as openclaw. Run exit to get back to root, then edit the file.

Q: I changed the env file but nothing changed

You need to restart the service. Run systemctl restart openclaw as root. The env file is only read at startup.

Q: My skill fails silently – no errors, no output

This is almost always the tools.exec.security setting. At lower tiers, OpenClaw will quietly block operations without telling you. Set it to full as root and restart.

Q: Commands seem to hang forever

Two likely causes. If tools.exec.host isn’t set to gateway, execution has nowhere to run on a headless VPS. If tools.exec.ask isn’t set to off, commands are waiting for approval that nobody can give. Set both and restart.

Q: Which user should I be for what?

• Installing skills, running tools → openclaw
• Editing env vars, setting policies, restarting the service → root