OpenClaw Deployment Part 1: The Fortress That Locked Itself Out

It's 9:30pm on a Tuesday. After entertaining the kids and spending some time with my wife talking about our days, I sat down at my desk with a singular mission: deploy OpenClaw securely on my M4 Mac Mini, using local AI with Ollama, locked down to the point where it would take a nation-state threat actor and a bad day at CISA to break in.

How hard could it be?

By 1:30am, I had learned three things: security and usability exist on a seesaw, AI tools are not inherently safe to run wide open, and Bob Ross was a wiser man than most security architects.

This is Part 1 of the OpenClaw Deployment series. It is the failure. Part 2 will be the comeback.

Why I Wanted to Secure OpenClaw in the First Place#

Let me explain what OpenClaw is for anyone who has not run across it yet.

Before I tell you about my deployment, I need to tell you why I was paranoid enough to spend hours designing a security architecture before writing a single config file. The answer is: the recent history of OpenClaw deployments is genuinely alarming.

The Real-World Incidents That Made Me Nervous#

In the two months before I started this project, the following things actually happened:

ClawJacked (CVE-2026-25253, CVSS 8.8 "High"): Researchers at OASIS Security disclosed a one-click remote code execution vulnerability. A malicious website could silently hijack a local OpenClaw instance by stealing the gateway authentication token over WebSocket. One tab open to the wrong site and your AI agent was under remote control.

40,000+ Exposed Instances: Researchers at Infosecurity Magazine and Bitsight found that 63% of observed OpenClaw deployments were vulnerable to remote code execution, with 12,812 instances directly exploitable. Why? Because OpenClaw's default configuration binds the gateway to 0.0.0.0:18789, which means it listens on every network interface, including the one that faces the internet if you are on a home network with any port forwarding at all.

Think about that for a second. More than twelve thousand people had an AI agent capable of running arbitrary commands exposed directly to the internet, by default, without realizing it.

The Moltbook Data Breach (February 2026): Moltbook, an OpenClaw-adjacent service, exposed 35,000 email addresses and 1.5 million agent tokens in plaintext through an improperly secured Supabase backend. Tokens that provided API access to users' AI agents, sitting unencrypted in a database.

283 Malicious Skills in ClawHub (February 2026): Snyk researchers found that 7.1% of skills in the ClawHub marketplace contained credential-leaking flaws. API keys, passwords, and credit card numbers were being passed through LLM context in plaintext and potentially exfiltrated. This is the AI equivalent of a Chrome extension that reads your passwords.

Container Network Isolation Bypass (GHSA-WW6V-V748-X7G9): A sandbox escape vulnerability allowing attackers to join container network namespaces via the container:<id> syntax, bypassing the network isolation that was supposed to prevent malicious code from phoning home.

The Cline npm Supply Chain Attack: A malicious npm package silently installed OpenClaw on Cline CLI users' systems without their knowledge or consent. This one is especially unsettling because it means the attack surface includes your CI/CD pipeline and any developer workstation running the affected version.

AMOS Stealer via SKILL.md (2026): Trend Micro documented a campaign where the Atomic macOS Stealer (AMOS) malware hid malicious instructions inside SKILL.md files. The attack exploited the fact that AI agents treat instruction files as trusted sources. The agent would read the file, follow the embedded instructions, and exfiltrate data, all while appearing to operate normally.

So. That is the threat landscape. An AI agent with local code execution, file system access, browser automation, and network connectivity, sitting on your laptop, potentially with its authentication port open to the world, loading skills from a marketplace that has a 7.1% malicious content rate.

Yeah. I wanted to secure it.

The Plan: Five Agents, Nine Phases, Zero Shortcuts#

This is where I did the thing I always do when facing a complex problem I care about: I brought in a team of AI security specialists.

Using Claude Code, I orchestrated a five-agent team to design the security architecture:

The output was a 9-phase deployment guide covering every layer of the stack. I am going to walk you through what we designed, because even in its over-engineered glory it contains some legitimately good ideas.

Phase 1: Docker Desktop Hardening#

Before OpenClaw ever starts, the container runtime itself gets locked down:

• Switch from Docker's default VMM to the Apple Virtualization framework (VirtioFS), which has a smaller attack surface and better performance on Apple Silicon
• Disable the default Docker socket (/var/run/docker.sock), which is a common privilege escalation vector
• Restrict Docker file sharing to /opt/openclaw only, preventing any container from accessing the broader filesystem
• Disable Rosetta (no x86 emulation, reducing attack surface)
• Hard resource limits: 4 CPU cores, 8GB RAM, preventing resource exhaustion attacks

Phase 2: Dedicated User Account#

One of the oldest security principles: least privilege. Create a standard (non-admin) macOS user account called openclaw, isolated from your personal files. OpenClaw runs as this user. Even if something breaks out of the application layer, it cannot touch your home directory, your keychain, or your admin-level configurations.

Phase 3: Locked-Down Workspace#

sudo mkdir -p /opt/openclaw/workspace
sudo chown openclaw:openclaw /opt/openclaw/workspace
chmod 700 /opt/openclaw/workspace

Two extra hardening steps the Red Team agent flagged:

• Create a .metadata_never_index file in the workspace. This tells Spotlight to skip the directory, preventing your AI agent's working files from being indexed and surfacing in system-wide searches.
• Disable mDNS discovery. By default, macOS advertises services on the local network. An AI agent running locally should not be broadcasting its presence.

Phase 4: The Hardened Security Config#

This is where the five-agent collaboration really shined. The Red Team engineer spent a full pass attacking the default OpenClaw configuration before the System Administrator locked it down. The result was an openclaw.json that read like a security checklist:

{
  "gateway": {
    "host": "127.0.0.1",
    "port": 18789,
    "auth": {
      "enabled": true,
      "token": "<32-byte-random-token>"
    }
  },
  "sandbox": {
    "mode": "all",
    "docker": {
      "network": "none",
      "readOnly": true
    }
  },
  "workspace": {
    "path": "/opt/openclaw/workspace",
    "accessMode": "read-only"
  },
  "tools": {
    "browser": { "enabled": false },
    "automation": { "enabled": false },
    "exec": { "requireApproval": true }
  },
  "filesystem": {
    "allowedPaths": ["/opt/openclaw/workspace"]
  },
  "discovery": {
    "mdns": false
  }
}

Phase 5: Isolated Docker Network#

Create a Docker bridge network with inter-container communication (ICC) disabled and IP masquerade disabled. The custom subnet (172.20.0.0/16) isolates OpenClaw's network traffic from other Docker workloads.

docker network create \
  --driver bridge \
  --opt com.docker.network.bridge.enable_icc=false \
  --opt com.docker.network.bridge.enable_ip_masquerade=false \
  --subnet=172.20.0.0/16 \
  openclaw-isolated

Phase 6: Red Team Threat Assessment#

The Red Team engineer generated a full attack tree covering:

• Container escape via mounted sockets and kernel vulnerabilities
• Network exposure via binding and mDNS
• Credential theft via environment variables and config files
• Prompt injection via malicious skill files (the AMOS vector)
• Supply chain attacks via npm and skill marketplace
• macOS-specific attacks via Spotlight indexing and Keychain access
• Sandbox bypass via the container:<id> network namespace trick (GHSA-WW6V-V748-X7G9)
• Data exfiltration via model output and log files

Each attack was rated for likelihood and impact, with mitigations mapped to configuration settings. It was genuinely thorough work. The kind of analysis that, in a professional context, would cost several thousand dollars.

I was very proud of this security architecture.

It was going to destroy me.

The Deployment: When Theory Meets Reality#

It is 9:30pm. I have the guide open in one terminal window and Claude Code ready to help in another.

Phase 1: Docker Setup (Mostly Fine)#

This went reasonably well. Docker Desktop installed without drama. I worked through the settings, disabled the default socket, locked down file sharing.

One snag: I needed to switch from Docker's default VMM to the Apple Virtualization framework to enable VirtioFS. This required a Docker Desktop restart and a few minutes of confusion about where the setting lived. Not a crisis.

Phase 2: Ollama (Smooth)#

brew install ollama
ollama pull llama3.2:3b
ollama serve

Pulled the llama3.2:3b model. Fast on the M4 chip. No issues. This would turn out to be the smoothest phase of the entire evening.

Phase 3: User Account and Workspace (By the Book)#

Created the openclaw standard user account in System Preferences. Switched to it. Created the workspace directory with the locked-down permissions.

sudo mkdir -p /opt/openclaw/workspace
sudo chown openclaw:openclaw /opt/openclaw/workspace
chmod 700 /opt/openclaw/workspace
touch /opt/openclaw/workspace/.metadata_never_index

Permissions verified correctly. Workspace looked clean. I was feeling good.

Phase 4: Installing OpenClaw (First Speedbumps)#

Here is where the guide started to diverge from reality.

The Node Version Manager installer script expects a .zshrc file to exist in the home directory. The openclaw user was freshly created and had no shell configuration files at all.

=> Profile not found. Tried ~/.bashrc, ~/.bash_profile, ~/.zshrc, and ~/.profile.
=> Create one of them and run this script again

Not a crisis. I manually created the file:

touch ~/.zshrc
echo 'export NVM_DIR="$HOME/.nvm"' >> ~/.zshrc
echo '[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"' >> ~/.zshrc
source ~/.zshrc

OpenClaw itself installed fine via npm. Then I ran the onboard wizard, which promptly presented me with options that did not match the guide I had just spent hours creating.

The wizard asked about model providers. I selected "Skip for now" since I planned to configure Ollama separately. Reasonable enough.

Phase 5: Security Config (Applied)#

Applied the hardened openclaw.json. No errors on write. Things still felt manageable.

Phase 6: Docker Network (First Real Failure)#

I ran the Docker network creation command as the openclaw user.

Error: failed to connect to Docker API: permission denied

Of course. The openclaw user is not in the docker group. Standard (non-admin) users cannot talk to the Docker socket. That was the whole point of making it a non-admin user.

I had to exit to my admin user to run Docker commands. The guide acknowledged this as a known limitation and suggested workarounds, but every workaround involved either adding openclaw to the docker group (weakening the isolation) or running Docker commands as a separate privileged process and passing results somehow.

I created the network from the admin account and moved on, making a mental note that the operational model of "run everything as the restricted user" was already compromised.

Phase 8: Verification (Two Failures)#

The verification phase had five checks. Two failed outright:

Check 3: Sandbox Container Test

# Run as openclaw user
openclaw sandbox test
Error: failed to connect to Docker API: permission denied

The sandbox could not create containers because the sandbox runs as the openclaw user, which cannot talk to Docker. The entire point of the sandboxing security model was that every command would run in an isolated container. That feature was now inoperative.

Check 5: File Sharing Verification

Could not be run by the openclaw user. Required admin access to inspect Docker Desktop's virtual machine configuration.

I had two of five verification checks failing before I even reached the first conversation.

Phase 9: First Conversation (The Spiral)#

This is where I want you to pour yourself a drink. Or if you are reading this in the morning, maybe get a second cup of coffee.

Attempt 1: The Command Does Not Exist#

The guide said to start a conversation with:

openclaw chat

Error: unknown command "chat"

Classic. As established earlier, I was running v2026.3.2. The chat command had been removed or renamed. After a few minutes of openclaw --help, I found openclaw tui as the replacement.

openclaw tui

not connected to gateway - message not sent

Right. The gateway was not running. I had forgotten to start it.

openclaw gateway

The terminal froze. The gateway had started and taken over the foreground process, blocking further input.

I killed it, restarted it in the background:

openclaw gateway &

Back to the TUI. This time it connected. Progress! I typed "hello" and hit enter.

Attempt 2: The Ollama Authentication Problem#

No API key found for provider ollama

And also this, in the same error batch:

Failed to inspect sandbox image: failed to connect to Docker API: permission denied

There it was again. Two problems simultaneously. I tried fixing the Ollama auth first.

export OLLAMA_API_KEY="ollama-local"

This set the environment variable for my shell session. It did not propagate to the gateway process, which was already running in the background with its own environment.

I killed the gateway, set the variable, restarted the gateway. The error persisted. OpenClaw was looking for the key in an authentication profiles file, not an environment variable.

openclaw config set models.providers.ollama.apiKey "ollama-local"

Applied successfully. Restarted gateway. Still getting the agent-level auth error. The config was being read at a different level than the command modified.

After some digging, the actual fix was creating an auth-profiles.json file manually:

# Had to use echo because heredoc failed on indentation
echo '{"version":"1","profiles":[{"id":"default","name":"Default","providers":{"ollama":{"apiKey":"ollama-local"}}}]}' > ~/.openclaw/agents/main/agent/auth-profiles.json

(The heredoc version failed because the openclaw user's shell was parsing the indentation in the document literally. A small thing that cost me fifteen minutes of "why is this JSON malformed?")

Restarted the gateway. The Ollama auth error went away.

Attempt 3: Disabling the Sandbox (The Irony Is Not Lost on Me)#

With the auth fixed, I sent another "hello". Got no response.

Checked the logs. The gateway was trying to initialize the sandbox container before processing any message, and the sandbox initialization was failing because the openclaw user still could not talk to Docker.

The sandbox mode was set to "all" in my security config, meaning every operation required a container. No container access meant no operations.

I tried disabling it:

openclaw config set agents.defaults.sandbox.mode "off"

Applied. But the running gateway process had already loaded its configuration. It needed a restart to pick up the change.

I was now toggling the primary security control of my hardened deployment to "off" in order to make it work at all. The irony was not subtle.

Attempt 4: Doctor, Doctor#

I ran the built-in diagnostics:

openclaw doctor --fix

Error: launchctl failed - no GUI session

The openclaw user was a headless service account with no graphical login session. launchctl, macOS's service management system, requires a user to be logged into a GUI session to register user-level launch agents. The openclaw user had never logged in graphically. It existed only as an SSH target.

This was another thing the guide had not fully accounted for. The dedicated user account model assumes the account is used only for running OpenClaw, which sounds clean in theory. In practice, it means a lot of macOS tooling that assumes a GUI session simply does not work.

Attempt 5: The Channel Problem#

After all the fixes (auth profiles created, sandbox mode set to off, gateway restarted three times), I sent another "hello".

The TUI showed the gateway status as "running." It showed the connection as "connected." The token counter in the corner was incrementing. Somewhere, something was happening.

No response.

I waited. Sent another message. "nothing?"

Nothing.

The TUI had a section called "channels." It was empty.

Channel is required (no configured channels detected)

I had been sending messages into a void. The gateway was accepting them, processing the session overhead, incrementing the token count (I watched it tick from 7k to 8k to 8.5k as I typed), but routing them nowhere because no channel was configured.

I tried to configure a channel through the TUI interface. The interface accepted the configuration. I restarted the gateway. The TUI still showed no channels.

I tried openclaw config set to add the channel programmatically. Sent another message. The token counter went up. No response from the model.

It was 1:27am.

1:30am: The Decision#

I sat back. Looked at what I had in front of me:

• Docker sandboxing: disabled (openclaw user cannot talk to Docker socket)
• Container network isolation: partially deployed (created from admin account, never tested)
• Browser tools: disabled in config (but the config loading sequence was uncertain)
• Dedicated user account: technically present, but launchctl did not work, openclaw doctor did not work, and I had been context-switching to admin for half the steps
• Ollama auth: working, after manually creating a JSON file that the onboard process should have created
• Channels: not configured, messages routing nowhere
• Gateway: running, using a non-trivial amount of memory to process messages that went nowhere
• My running token count: 8.7k out of 131k context window

The token counter was the detail that broke me. It was quietly eating my context window processing "hello" and "nothing?" and "do something" while returning silence. I was paying computational debt for a conversation that was not happening.

I typed three final commands:

openclaw uninstall
npm uninstall -g openclaw
rm -rf ~/.openclaw ~/.nvm ~/.zshrc

Then cleaned the workspace and removed the Docker network from the admin account. Wiped clean.

Threw in the towel.

The Commute Epiphany#

The next morning, driving to work, I ran the whole thing back in my head.

I had over-engineered it. Not in the "I put in extra effort and it paid off" sense. In the "I tried to solve problems I did not have yet with solutions I did not understand well enough to implement correctly" sense.

The dedicated user account was a good idea that failed because I did not account for macOS's assumption that users have GUI sessions. The Docker sandboxing was a good idea that failed because I did not verify that the restricted user could access Docker before basing the entire security model on that assumption. The channel configuration was something I had not understood at all before I tried to configure it with security restrictions around it.

I had skipped the part where you learn how the thing works before you secure the thing.

Bob Ross used to say, on his PBS painting show, that there are no mistakes, only happy little accidents. He meant it. When a brush stroke went wrong, he would turn it into a tree, or a cloud, or a shadow that the painting needed but he had not planned. The mistake was not a setback. It was information that changed the composition.

My 9:30pm-to-1:30am OpenClaw disaster was not a wasted evening. It was a very expensive hypothesis test that generated extremely useful data:

1. OpenClaw v2026.3.2 does not have a chat command. (Documentation drift is real and matters.)
2. The openclaw user cannot talk to the Docker socket without being added to the docker group. (Least privilege and Docker access are fundamentally in tension.)
3. launchctl requires a GUI session. (Headless service accounts have limitations on macOS that are not documented in most deployment guides.)
4. Channels must be configured before messages can be routed. (The onboard wizard's "Skip for now" option skips things you actually need.)
5. My security architecture was designed for the last step, not the first. (You cannot secure something you do not yet understand how to run.)

The New Plan#

On the commute, I outlined a different approach. Not "strip the security and give up." More like "start where I should have started."

Phase 1: Get it running with zero security constraints. Install as my normal user. Use the default configuration. Configure Ollama. Get a message to go through and get a response back. Understand what "working" looks like before I start modifying it.

Phase 2: Add one security layer. Just one. Probably the gateway binding (change from 0.0.0.0 to 127.0.0.1). Verify it still works. Understand what changed.

Phase 3: Add the next layer. Understand it. Verify it. Repeat.

This is the scientific method, applied to security architecture. Form hypothesis. Test it in isolation. Collect data. Move to the next hypothesis only after you understand the current one.

The 9-phase security guide I had created with my five-agent team was not wrong. Most of the controls it described are genuinely good ideas. But it was a guide for an expert who already understood how OpenClaw worked and was adding hardening on top of a running, understood system.

I had tried to follow it as a beginner's setup guide. That was the mistake.

What Comes Next#

Part 2 of this series is where I actually get OpenClaw running. First without any security controls, just to see it work. Then methodically, one layer at a time, with verification after each step.

I am going to document the whole thing: every command, every error, every config file, every moment where something did not work the way I expected. The point is not to arrive at a perfect finished product but to show the process of learning a tool by using it, failing, understanding the failure, and trying again.

Because here is the thing about failure: it is not the opposite of learning. It is the mechanism of learning. Every time something does not work the way I expected, I know something true about the system that I did not know before. That is not nothing. That is data.

And data is where security architecture starts.

Lessons from the Disaster#

The Series So Far#

This is Part 1 of the OpenClaw Deployment series. It is the failure story. Part 2 will cover the fresh start: getting a basic working deployment, then adding security controls incrementally with verification at each step. Part 3 (if I get there) will revisit the full security architecture from Part 1, this time applied to a system I actually understand.

If you have deployed OpenClaw successfully, especially with local Ollama models on macOS, I would genuinely love to hear what worked for you. The comments section exists for exactly this kind of thing.

And if you have spent a night watching a terminal do nothing at 1:30am, you are not alone. It happens to everyone. The question is what you learn from it.

Written by Chris Johnson. Every error message in this post was real. Every command was actually run. Every failure was actually experienced, at the actual hours listed, on an actual Tuesday night. The security architecture was designed with Claude Code agents and is documented in the companion guide. Part 2 of this series is in progress.