DEV Community: Eugene Kovshilovsky

The OpenClaw Problem, or: How I Stopped Wrapping Docker in VMs and Built a One-Command Setup Instead

Eugene Kovshilovsky — Fri, 27 Mar 2026 19:02:47 +0000

A continuation of 128GB of RAM, Zero Internet, and a Year of Building AI Infrastructure Nobody Asked For

When I shipped headless agent mode for Cloister, I thought I'd solved the hard problem. VM isolation, consent policies, credential forwarding — all the security layers you'd want between an autonomous AI agent and your actual life. The next step was obvious: run OpenClaw inside it.

OpenClaw is an open-source AI agent framework — a persistent assistant that connects to Telegram, WhatsApp, iMessage, and runs tasks on your behalf. It has a gateway (the brain), nodes (execution endpoints), and a sandbox for running arbitrary code. It's powerful. It's also the kind of software whose community has been refreshingly honest about: don't run it on bare metal.

So I didn't. I ran it inside a Cloister VM. Inside Docker. Inside a Linux VM. On macOS.

If that sentence made you wince, you're ahead of where I was.

Three Security Bypasses and a Caddy Proxy

The first sign something was architecturally wrong came when I tried to access OpenClaw's Control UI through an SSH tunnel. Three things broke, each requiring a security bypass:

CSP Header. OpenClaw's CSP hashes didn't match its actual inline scripts. The UI rendered as a blank page. Fix: a Caddy reverse proxy to strip and replace the header. Not ideal.
Device Auth. Docker NAT meant the gateway saw 172.18.x.x instead of 127.0.0.1, triggering device pairing over HTTPS — which SSH tunnels don't provide. Fix: dangerouslyDisableDeviceAuth: true. The flag's name judged me every time I opened the config.
Gateway Bind. Loopback binding + Docker port publishing don't mix. Fix: gateway.bind: lan, which is exactly what the security docs tell you not to do.

I rationalized all three: "The VM has three isolation layers. Even with bypasses, the blast radius is contained." Technically true. Also a Rube Goldberg machine where each layer existed to compensate for the layer below it.

Then I found OpenClaw's Lume documentation.

The "Wait, They Already Solved This" Moment

OpenClaw has a docs page titled "macOS VM." I'd skimmed past it. When I actually read it:

Lume runs macOS VMs on Apple's Virtualization.framework — same hypervisor tech Cloister uses through Colima for Linux, but with macOS guests. The key differences that made me rethink everything:

No Docker. OpenClaw installs natively. It has its own sandbox — the one I was redundantly wrapping in another Docker layer.
No CSP bypass. Gateway runs on actual localhost. No NAT, no proxy.
No auth bypass. Connections come from real localhost. Device pairing just works.
No bind hack. Gateway stays on loopback. Everything works as documented.
iMessage access. Lume VMs are real macOS — they can run BlueBubbles for iMessage bridging. Linux VMs can't. Ever.

Five problems solved by removing a layer of abstraction. I chose the option that meant admitting the layer I'd built was wrong: abstract the VM backend so Cloister supports both. Colima for Linux workloads, Lume for macOS. The user says --openclaw, Cloister picks Lume. The user creates a regular profile, Cloister picks Colima. Nobody needs to know which hypervisor is underneath.

The Installation Gauntlet

If you've tried setting up a Lume macOS VM yourself, you've probably already rage-quit once. Here's what actually happens:

The IPSW download. Lume creates a macOS VM from Apple's ~18GB restore image. It downloads to a temp directory. If the setup fails — and it will — the download is gone. Next attempt? Another 35 minutes on a decent connection. I built IPSW caching into Cloister so it downloads once, keeps it at ~/.cloister/cache/ipsw/, and reuses it across every attempt and every profile. The kind of feature nobody thanks you for until they don't have it.

The version mismatch. Apple's Virtualization.framework refuses to install a macOS guest newer than the host. It downloads the 18GB IPSW, starts the install, and rejects it after 25 minutes. I added a preflight check that parses the IPSW filename version, compares against sw_vers, and fails in five seconds instead of twenty-five minutes.

The Setup Assistant. Lume automates the macOS Setup Assistant by clicking through 167 UI elements via VNC. On macOS 26.4, Apple renamed a button. Step 66 of 167 fails. Every time. This is an upstream Lume issue — if you're doing it yourself, you'll need to create the VM without --unattended and click through setup manually via VNC. Five minutes by hand. Not ideal, but you only do it once per base image.

The base image. Cloister solves this with a shared base image that every OpenClaw profile clones from. First profile: 15-20 minutes. Every subsequent one: about 2 minutes. Plus snapshots — factory (after provisioning) and user (your fully configured state) — so cloister reset gets you back to working in under two minutes.

If you're setting this up without Cloister, budget an afternoon and a decent internet connection. Or save yourself the trouble.

The Real Problem: Nobody Knows Where to Start

The Lume setup gets you a blank macOS VM. Congratulations. Now you need to:

Configure passwordless sudo
Install Xcode Command Line Tools, Homebrew, Node.js, Playwright, OpenClaw
Run the OpenClaw daemon onboard with the right flags
Set up a Telegram bot via BotFather
Figure out your Telegram user ID (hint: message @userinfobot)
Configure Ollama as a provider — but first figure out the VM's bridge gateway IP
Set up Google OAuth for Gmail, Calendar, Drive — but the OAuth callback goes to localhost, and you're inside a VM, so you need an SSH tunnel
Deal with the macOS keychain password that drifted from the user password during headless setup
Register the node host with OpenClaw's device pairing system
Approve the device — but not with --all because that flag doesn't exist, it's --latest

Each of these has at least one gotcha that'll cost you 30 minutes of Googling — or 30 seconds of asking ChatGPT, which will confidently hallucinate the wrong config field name and cost you an hour. Some have gotchas that'll cost you a day.

I know because I hit every single one of them.

`cloister setup openclaw`

So I built a wizard.

cloister create --openclaw my-oc    # Create the Lume VM (clones from base image)
cloister setup openclaw my-oc       # One command. Handles everything.

The wizard runs five sections in order. Each one writes config and credentials immediately — never batches at the end. If your WiFi drops halfway through, re-running the wizard picks up from the last completed step.

Credentials. Detects 1Password CLI. If found, stores everything there with Touch ID. If not, asks if you want to install it or use local encrypted storage. Generates a new keychain password (because the headless setup almost certainly left it in a state where the old one doesn't work), stores it before applying it to the VM (credential sync invariant — never change a password you haven't recorded), and stores the VM user credentials.

Channels. Walks you through BotFather for Telegram — or accepts an existing bot token. Collects your user ID with instructions to message @userinfobot. Writes the config with dmPolicy: allowlist and allowFrom locked to your Telegram ID. I initially used allowedUserIds because that's what seemed logical. OpenClaw rejected it. The actual field is allowFrom. The kind of thing where you stare at a "Config invalid" error for twenty minutes before realizing the docs and the schema disagree.

WhatsApp gets configured as an action-only channel — OpenClaw can send you notifications, but nobody can issue commands through it. Safe defaults: allowCommands: false, allowFrom locked to your number, escalationPolicy: deny. Because the last thing you want is someone in a WhatsApp group accidentally telling your AI agent to rm -rf /.

Providers. Auto-detects Ollama on the VM's bridge gateway IP. Lists available models. Offers to pull qwen3:32b if nothing's loaded. Then asks the real question: local inference (free, fan sounds like a jet engine) or Anthropic Claude (costs money, quiet). Both can be registered simultaneously — you just pick a default. The wizard handles the API key collection and 1Password storage.

Google OAuth. This one was fun. gog (the Google CLI) needs to run inside the VM, but the OAuth callback redirects to localhost — which is the VM's localhost, not your Mac's. The wizard picks a random high port (49152–60999, collision-checked), sets up an SSH tunnel, runs gog auth add with --listen-addr 0.0.0.0:<port>, and the callback routes through the tunnel back to gog. You just paste the URL in your browser and click Allow.

Except gog's file-backed keyring needs a password to encrypt tokens, and there's no TTY available for the prompt. The wizard sets GOG_KEYRING_PASSWORD to the keychain password it already stored. Another 45 minutes of debugging, now a single environment variable in the setup flow.

Device Pairing. Registers the node host, writes trusted proxy config, approves pending devices, and runs openclaw gateway probe to verify the whole thing is actually healthy — WebSocket connectivity, RPC health, auth warnings. Not just "is the process running" but "can we actually talk to it."

The whole flow takes about 3 minutes on a running VM. Non-interactive mode works too:

cloister setup openclaw my-oc \
  --telegram-token="BOT_TOKEN" \
  --telegram-user-id="USER_ID" \
  --default-provider=ollama \
  --ollama-model=qwen3:32b \
  --google-client-secret=~/client_secret.json \
  --google-email="you@gmail.com"

And for AI agents that want to discover what's configurable:

cloister setup openclaw my-oc --list-options --json

The Config Serialization Bug That Almost Ate Everything

While building the wizard, I discovered that older versions of Cloister (the one installed via Homebrew) would silently drop the backend: lume field when saving config. Go's yaml.v3 library ignores struct fields it doesn't recognize during unmarshal, so the old binary would load the config, not understand backend, and write it back without it. Next time the new binary loaded the config, it would default to Colima and everything would break.

The fix was three things: remove omitempty from the Backend field (always serialize it), add a config version number (so we can detect and migrate), and rotate config.yaml to config.yaml.prev before every save. If anything goes wrong, your previous config is one file rename away. Simple, boring, correct.

The Agent Command That Had to Die

The original Cloister had a whole agent subcommand tree — agent start, agent stop, agent status, agent logs, agent forward. This made sense when OpenClaw ran inside Docker inside a Linux VM. The VM was one thing, the Docker container was another, and you needed separate controls for each.

With Lume, the VM is the agent. OpenClaw runs as a launchd service, not a Docker container. There's no separate lifecycle to manage. So I replaced the entire agent subcommand tree with unified profile commands: cloister status shows everything (both backends, VM state, gateway health), cloister logs tails the gateway log, cloister stop stops the VM. One interface, regardless of what's running underneath.

The old cloister agent command now prints a polite deprecation message pointing to the new commands. Because breaking people's muscle memory without a breadcrumb trail is rude.

What I Learned (Again)

When I hit the Docker networking problems, my instinct was to add complexity. A proxy for the CSP. A flag to disable auth. A bind override. Each solution was individually defensible. Together, they formed a tower of compensating controls that existed only because the foundational decision — running a macOS-native application inside Docker inside Linux inside macOS — was wrong.

The Lume approach doesn't need any of those fixes because it doesn't create any of those problems.

Removing abstraction layers is harder than adding them. You have to admit the layer you built was wrong. You have to resist the voice that says "but it works fine with the three workarounds." It does work fine. But when you're building infrastructure that autonomous AI agents run on, "fine" is measured in security bypasses you hope nobody exploits.

The setup wizard is the part I'm most satisfied with. Not because the code is clever — it's mostly prompts, SSH commands, and state tracking — but because it encodes every gotcha, every undocumented field name, every TTY password issue, every keychain drift problem into a flow that takes 3 minutes instead of a day. The next person who wants to run OpenClaw in an isolated macOS VM doesn't need to learn any of this. They just run one command.

That's what infrastructure is supposed to do: absorb complexity so the user doesn't have to.

ekovshilovsky / cloister

Run multiple Claude Code accounts & AI agents on one Mac — isolated macOS VMs with secure sandboxing

Cloister: Isolated VMs for AI Agents & Multi-Account Claude Code on macOS

Isolated macOS VM environments for running multiple Claude Code organizations, sandboxing autonomous AI agents like OpenClaw, and separating credentials across client engagements.

Why cloister?

Multi-account isolation. Claude Code stores credentials, conversation history, and project config in ~/.claude. If you work across multiple organizations, every session shares the same identity. cloister gives each account its own isolated VM with separate credentials, CLAUDE.md, and conversation history.

Autonomous agent containment. AI agents like OpenClaw run 24/7 with shell access, browser control, and cron scheduling. cloister's VM isolation is stronger than Docker (separate kernel, not just namespace isolation) — services inside the VM are unreachable from the host unless explicitly tunneled, and cloister stop is an instant kill switch.

Dual-backend architecture. Colima (Linux VMs) for Claude Code isolation and Docker workloads. Lume (macOS VMs via Apple Virtualization Framework) for OpenClaw…

View on GitHub

cloister — Isolated VM environments for AI coding agents and multi-account separation. Dual-backend: Colima (Linux) and Lume (macOS). One-command OpenClaw setup.

op-forward — Forward 1Password CLI across SSH boundaries with biometric authentication.

128GB of RAM, Zero Internet, and a Year of Building AI Infrastructure Nobody Asked For

Eugene Kovshilovsky — Fri, 20 Mar 2026 02:28:54 +0000

Most people who know me professionally won't see my name on LinkedIn attached to a company right now. That's intentional. It's not that I'm between roles, it's that the moment you attach a title and a company name to yourself on this platform, your inbox becomes a graveyard of BizDev pitches, QA outsourcing firms promising to "augment your team," and vendors who want to "explore synergies" over a 30-minute call that could have been a "no." I've done that dance for years. I'd rather write code.

What I will say: I'm still a CTO. I'm still leading technical strategy. The scope has changed, and I'm working with a smaller, sharper group of people on things I actually care about, but the role hasn't. I just happen to be writing a lot more code than I have in a decade, and that is the point of this article.

The Shift

About a year ago, I was running e-commerce engineering at CarID. Large teams, enterprise-scale platform, the usual orbit of architecture reviews and vendor evaluations. Over the years I'd pushed hard for modern data tooling through Delta architectures, real-time pipelines, and I'd wave-tested every AI tool that came across my desk. GitHub Copilot, early LLM integrations, various coding assistants. My honest assessment each time was the same: interesting, but I wouldn't let it near a production PR.

Then, around February and March of 2025, something shifted. Not gradually! It felt like someone flipped a switch while I wasn't looking. Models got reliable enough to trust with real work. Claude Code shipped and it wasn't a toy or a glorified autocomplete, it was a genuine development partner that could hold context, reason about architecture, and do actual engineering. The ecosystem around it started moving fast, and for the first time in years, I felt like I was watching something I needed to be inside of, not evaluating from a distance.

By mid-April 2025, I left CarID. In my free time, I moved into building AI-powered developer infrastructure, the kind of tooling that makes the difference between AI being a novelty and AI being a force multiplier. I'm still leading and setting technical direction, making architecture decisions, building systems but I'm also deeper in the work itself than I've been since the early days of my career.

And I am very willing to get my hands dirty.

What started as "let me properly integrate AI into my workflow" turned into a year-long obsession with building with AI reliably, securely, and without depending on things I can't control. Along the way, I recently decided to open-source the pieces because I realized the problems I was solving weren't just mine.

The Problem Nobody Warns You About

Here's the thing about using AI seriously across multiple contexts: the tools assume you're one person with one account doing one thing.

That's adorable.

I have work projects with confidentiality requirements. I have personal projects I'm developing on my own time with my wife and kids. I would never use company resources for personal development, and I'd never mix personal context with professional context. That's not how I operate, the Gemini in me, and if you've ever worked in enterprise, you know that's not how anyone should operate.

So I ended up with multiple Claude Code licenses, multiple LLMs, multiple agents running simultaneously and a very practical problem: how do you keep all of this isolated on one machine without everything bleeding into everything else?

I found out the hard way that Claude Code's config isolation is broken. Instructions from one context started showing up in sessions for another. Not obviously but subtly, in ways that only became visible over time. The digital equivalent of accidentally presenting the wrong client's slides, except it happens silently. That's the kind of thing that erodes trust in your tools, and trust is the whole game when you're delegating real work to AI.

So I Did What Any Reasonable Person Would Do...I Built a VM Orchestrator!

When config-level isolation doesn't work, you need process-level isolation. Separate filesystems. Separate kernels. Real boundaries. Normal people might just log out and log back in. I chose violence.

I built cloister, an open-source CLI that creates lightweight Linux VMs using Apple's Virtualization Framework, where each profile gets its own isolated environment while sharing your code workspace, SSH keys, and Claude Code plugins. Type "cloister work" and your terminal background changes color, tunnels auto-discover host services, and you're in an isolated shell with Claude Code installed. Everything works, nothing leaks.

But getting here wasn't a straight line. Not even close.

The War Stories

My M5 Max has 128GB of RAM. Absolute unit. When I tried to run Ollama with a 27-billion-parameter model on it, it crashed immediately. After a day of debugging Metal shader compiler output, I found the issue: six lines of code mixing bfloat and half types in a matrix multiplication kernel. The fix had been merged upstream three months earlier, but Ollama hadn't synced it yet.

Six lines.

Between a working 27B model and me on the most powerful laptop Apple makes. Sometimes the universe has a sense of humor. I cloned Ollama from source, applied the fix, and wrote up a full diagnostic guide so other M5 owners don't have to go through the same detective work.

Then I learned that Apple does not expose Metal GPU access to Linux VMs through any hypervisor API. None. Zero. Apple looked at that feature request and said "no" in every API they ship. The workaround, a Vulkan translation through three layers, is the GPU equivalent of translating English to French to Japanese to get your point across at a dinner party.

So I tunneled around it. Ollama runs on the host with native Metal acceleration, and an SSH reverse tunnel forwards it into each VM. Full GPU speed, zero translation overhead, and the VM is just a thin client sending prompts and receiving tokens.

Along the way I also discovered that NVM silently breaks bash strict mode, GPG commit signing is a three-layer lock-contention nightmare in VMs, Claude Code switched installers mid-project, and a single Claude session can consume 37GB of virtual memory. I lost a 20-minute coding session to an OOM kill before I learned to allocate proper swap.

Credentials Shouldn't Live in Plaintext

One of the things that kept me up at night about running AI agents in VMs was credential management. The standard approach is to export API keys as environment variables in plaintext, sitting in memory, accessible to any process that asks nicely.

Inside a VM running autonomous agents with a published history of 512 security vulnerabilities? That's not a security concern. That's a security invitation.

I built op-forward, a daemon-tunnel-shim that forwards 1Password CLI commands from the VM to the Mac host, where Touch ID handles the authentication. Every credential access triggers my actual fingerprint. If the VM is compromised, the attacker gets an op binary that responds to every request with the digital equivalent of "go ask your mother."

I also built a consent system for the VMs themselves. Interactive profiles get full access to host services such as clipboard, 1Password, Ollama. Headless agent profiles get nothing unless explicitly whitelisted. SSH keys, GPG keys, Downloads are locked out by default. It's like giving your house keys to a stranger because they promised to only use the kitchen. Except I don't give them the keys.

Working at 35,000 Feet

This is the part that matters most to me.

Picture this: I'm on a flight. The guy next to me is watching downloaded Netflix episodes. The WiFi costs $8 and delivers bandwidth that would have embarrassed a 56k modem.

I'm running a 27-billion-parameter language model doing code review on my laptop. Locally. On a GPU that Apple won't let my VMs touch directly, so I tunneled around the restriction.

When the model needs a database password, it asks 1Password through a daemon-tunnel-shim chain that triggers Touch ID. The VM's Claude Code session has its own credentials and history and is completely isolated from every other context on my machine.

No internet. No API calls leaving the aircraft. No tokens counted against a rate limit.

I can disconnect my Mac from the internet and keep working. Fully. The entire AI development stack runs on one machine with zero external dependencies.

That's not an accident. That's what I designed for, because I got tired of my productivity being at the mercy of someone else's infrastructure.

What This Year Taught Me

The biggest shift wasn't technical. It was in how I think about leverage.

For most of my career, leverage meant hiring. More people, more output. Simple math, complicated HR.

Now, leverage means infrastructure. The right local setup lets one person do what used to require a team. Not because AI replaces people...please, let's retire that talking point, but because it changes the bottleneck. The bottleneck used to be typing speed and debugging time. Now it's context management, credential security, and compute orchestration. Nobody taught us this in management training.

The CTO title hasn't changed, but what the job feels like has. I spend less time in meetings about product design and architecture and more time building directly. I spend less time reviewing pull requests and more time pair-programming with an AI that doesn't care if I refactor the same function four times.

The tools I've built this year aren't products I'm trying to sell. They're infrastructure I needed to work the way I want to work. I open-sourced them because I think more people are going to need this same infrastructure, and I'd rather they spend their time building things instead of solving the same plumbing problems I already solved.

What's Next

If you're a senior technical person who's starting to work with AI seriously and not just asking it to explain regex, but actually integrating it into your workflow, then you're going to hit these walls. The identity isolation wall. The GPU acceleration wall. The credential security wall. The "what happens when the internet goes down" wall.

I've hit all of them, usually face-first. Here's what's on the other side.

cloister — Isolated VM environments for AI coding agents and multi-account separation.

op-forward — Forward 1Password CLI across SSH boundaries with biometric authentication.

M5 Metal 4 fix guide — Step-by-step diagnostic and fix for Ollama on Apple M5 chips.