DEV Community: Mehul Bhardwaj

Can OpenClaw Read Your Files? Here's What's Actually True.

Mehul Bhardwaj — Tue, 14 Apr 2026 04:23:44 +0000

A colleague who runs a consulting practice told me he'd read something online suggesting that OpenClaw would read all his data and that client information could end up in the wrong hands. He wanted to know whether he needed to do some kind of data cleanup before running it, and whether his clients' information was safe.

The answer is no cleanup needed, and yes the data is safe. But the reason matters, because "trust us, it's fine" is not an answer for a professional who carries liability for their clients' information. Here is the actual mechanism.

The Vessel is a separate computer

When you run OpenClaw through Vessel, it does not run on your machine. It runs inside a dedicated virtual machine in the cloud. That VM is the Vessel.

Your laptop and the Vessel are two distinct computers. They do not share a file system, they do not share memory, and there is no network path between them except the one you open when you visit the Vessel dashboard in your browser. Your Documents folder, your client files, your financial records, your desktop: none of these are on the Vessel. They are on your machine. The Vessel has never seen them and has no way to reach them.

This is not a permissions setting. It is not a policy. It is a physical separation. The agent lives in the cloud. Your files live on your hardware. Those are two different computers.

So the question "will OpenClaw read my files" has a simple answer when you run it on Vessel: it cannot, because your files are not there.

What OpenClaw can access

The Vessel contains OpenClaw and the connections you have explicitly authorized. That is the full inventory of what the agent can see.

If you connect your Gmail account, it can read and send email from that account. If you connect Slack, it can read and send messages in the channels you permit. If you connect your calendar, it can read your schedule. These connections go through standard authorization flows, the same ones you use when you allow any application to connect to Google or Slack. You approve each one. You define the scope.

That list is the entire perimeter. Nothing on your laptop is inside it. Nothing you have not explicitly connected is inside it.

What happens if someone hacks the Vessel

This is the second question worth answering directly, because "separate computer" raises an obvious follow-up: what if someone gets into that computer?

Each Vessel is an isolated virtual machine. The isolation is enforced at the hardware level by the cloud infrastructure it runs on. One VM cannot read the memory of another VM. One VM cannot access the disk of another VM. This is not a software promise, it is how the underlying hardware virtualization works. Google Cloud Platform's hypervisor enforces it at the physical level.

This matters for two reasons.

First, if someone compromised your Vessel, they would get a Linux box running OpenClaw, plus whatever services you had connected via OAuth. They would not get your local files, because those are on your machine, not the Vessel. The blast radius is bounded.

Second, if someone compromised any Vessel, they would not be able to cross into another customer's Vessel. Each one is walled off from every other one at the hardware level. This is structurally different from shared container hosting, where a container escape can put an attacker on the host machine that other containers share. On dedicated VMs, that path does not exist.

Compare: running OpenClaw on your laptop

Running OpenClaw locally is not the data disaster people imagine, but it does create a different risk worth understanding.

The agent still cannot read arbitrary files it was not given access to. That part is the same. What changes is that your agent is now running on the same machine as everything sensitive you own. Your client contracts, your financial records, your saved credentials: all on the same hardware as the agent process. If something goes wrong with the software, you are dealing with it on the machine that holds everything.

Running on a dedicated Vessel means those two things never share a machine. Something going wrong on the Vessel stays contained to the Vessel. Your laptop remains what it was before: a separate computer that the agent has no access to.

The LLM API question

One more concern worth addressing: when OpenClaw processes a request, it sends a prompt to the AI model you have configured (Anthropic, OpenAI, or Google Gemini) through their API. That conversation does travel to their servers. This is not hidden and it is not unique to OpenClaw. It is exactly the same data flow as pasting a document into Claude or ChatGPT yourself.

All three major providers are explicit that paid API traffic is not used for model training.

Anthropic: "We will not use your chats or coding sessions to train our models, unless you choose to participate in our Development Partner Program." (source)

OpenAI: "Data sent to the OpenAI API is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us)." (source)

Google Gemini: "When you use Paid Services, Google doesn't use your prompts or responses to improve our products." (source)

One caveat: Google's free Gemini API tier operates under different terms and does use content for product improvement. Vessel uses the paid API tier, so the above applies.

The practical point in all three cases is the same: the data that travels to the model is only the content you put into the conversation. It is not a background sweep of your files. It is not ambient collection. It is a deliberate API call with the context you chose to include.

The memory and context that OpenClaw builds over time, the knowledge it accumulates about how you work, stays on the Vessel. On shared hosting, that server belongs to someone else. On a dedicated Vessel, it belongs to you.

No cleanup needed, and here is why

My colleague asked whether he needed to sanitize his systems before running an AI agent. The reason the answer is no: the agent is not on his systems. It is on a separate computer in the cloud that has never seen his local files and cannot reach them.

The question worth asking before you start is not "what is on my machine that the agent might find." It is "what services am I going to connect to this agent, and am I comfortable with it acting on my behalf in those places." That is a much narrower question, and it is entirely in your control.

Make a short list of the connections you plan to authorize. Gmail, Slack, calendar, whatever is relevant to the work you want it to do. That list is the perimeter. Everything outside it remains exactly where it is.

The structural answer

The privacy guarantee here is not a promise made in a terms of service. It is a consequence of architecture. The Vessel is a separate computer. Your files are on a different machine. Hardware-level VM isolation means no other customer's Vessel can see yours, and yours cannot see theirs.

For a professional who carries accountability to clients, that distinction matters. "We promise not to look" is a policy. "There is no path from that machine to your files" is a structure.

I'm building Vessel, dedicated private hosting for OpenClaw agents. Each agent runs on its own isolated server in the cloud. More on how the isolation works: vesselofone.com/platform/security and vesselofone.com/why/isolation.

What Self-Hosting OpenClaw Actually Costs (It's Not Just the VPS)

Mehul Bhardwaj — Sun, 05 Apr 2026 06:30:40 +0000

Every deployment guide says self-hosting OpenClaw costs $5-20/mo. I believed that too, until I started tracking where my time actually went.

The VPS was the cheapest part of the whole operation.

What Everyone Budgets

You find a deployment guide. It walks you through spinning up a VPS, pulling the Docker image, setting up a reverse proxy. At the end, you do the math: maybe $7 on Hetzner, $48 if you want DigitalOcean's SLA. Add a domain, Let's Encrypt, your own API keys. Call it $20-100/mo depending on how fancy you get.

For reference, here's what a 4 vCPU / 8 GB instance actually costs in 2026:

Provider	Monthly	The catch
Contabo	~$5	Oversold shared vCPUs. Performance varies.
OVH	~$6.50	Free daily backups. Honest value.
Hetzner	~$9	No SLA. US regions get 1 TB transfer, not 20 TB. Price increased Apr 2026.
GCP (1yr commit)	~$37	On-demand is $49. Add $3-5 for disk.
Vultr	$40	Straightforward. No surprises.
DigitalOcean	$56	Best SLA. Best marketplace. Price reflects it.

Feels reasonable. You pick a provider, provision the box, get the agent running. Whole thing takes an evening.

And then the month starts.

Week 1: The Patch

OpenClaw ships patches 2-3 times a month. Not feature releases. Security patches. The kind you can't ignore because the last round of CVEs included a pre-auth remote code execution.

So Tuesday morning, I see the release. Pull the new image. Read the changelog to make sure nothing breaks. Restart the container. Verify the agent comes back and the skills still load.

45 minutes. Fine. That's the job.

Week 2: The Key I Forgot About

Routine API key rotation. I open the docker-compose file and there it is. The OpenAI key, hardcoded directly in the environment block. Not pulled from .env. Just sitting there in plaintext, committed to a private repo I haven't thought about since setup day.

# How it was (bad)
services:
  openclaw:
    environment:
      - OPENAI_API_KEY=sk-proj-abc123...

# How it should have been
services:
  openclaw:
    env_file:
      - .env

I know better than this. Everyone knows better than this. But setup day was three weeks ago, and setup day me was in a hurry to see the agent respond to a message. Setup day me cut a corner and moved on.

Rotated the key. Fixed the compose file. Tested everything. 50 minutes, plus the quiet dread of wondering how long that key was sitting there.

Week 3: The Silent Failure

This one cost me three hours and some trust.

The agent had been silently disconnecting from the gateway every six hours or so. No error in the container logs. No alert. Nothing in the dashboard. From my side, everything looked fine.

From the user's side, they'd open the chat and get nothing. Just silence. For how long before I noticed? I don't actually know. That's the part that bothered me.

The fix was a health check I should have written on day one:

#!/bin/bash
response=$(curl -s -o /dev/null -w "%{http_code}" http://localhost:18789/health)
if [ "$response" != "200" ]; then
  docker restart openclaw-agent
  echo "$(date): Agent restarted" >> /var/log/openclaw-health.log
fi

# crontab: every 5 minutes
*/5 * * * * /opt/openclaw/health-check.sh

Three hours of debugging. The silent part was worse than the broken part. An agent that crashes loudly is annoying. An agent that fails quietly erodes confidence.

Week 4: Sunday Night

11pm on a Sunday. A skill tried to load a large PDF into context. The container hit its memory ceiling. The kernel OOM-killed it. No graceful shutdown, no notification, no restart. Just gone.

I found out Monday morning when I saw a client message that had gone unanswered for nine hours.

90 minutes to set up memory limits and alerting. The kind of work that feels urgent at 7am on a Monday, standing in the kitchen, coffee not yet made, reading a notification that should have woken me up at 11pm but didn't because the alerting didn't exist yet.

Adding It Up

Here's what the month cost:

	Hours	What happened
Security patching	~1 hr	One patch cycle. Some months it's two.
Credential rotation	~1 hr	Plus the cold sweat of finding a hardcoded key.
Monitoring + debugging	~3 hrs	The silent WebSocket failure.
Unplanned incident	~1.5 hrs	Sunday night OOM kill.
Total	~6.5 hrs

Call it 4-7 hours in a typical month. Some months less. Some months the WebSocket thing happens and it's more.

Now put a number on your time. If you bill $100/hr (and if you're running an AI agent for professional work, your rate is probably higher), that's $400-700/mo in time. On top of whatever you pay for the VPS.

Provider	Infra cost	+ Time (4 hrs × $100)	What you actually pay
Hetzner	~$9	$400	~$409/mo
OVH	~$7	$400	~$407/mo
Vultr	~$48	$400	~$448/mo
DigitalOcean	~$56	$400	~$456/mo

Pick any provider. The VPS is a rounding error. You're paying $400/mo no matter where the box lives.

This Isn't Like Self-Hosting Plex

I've self-hosted plenty of things. Nextcloud. Plex. Home Assistant. Gitea. None of them cost me this much time per month.

AI agents are a different animal. External API keys that expire on different schedules. A patch cadence of 2-3 times a month because the security surface is still being mapped (14 CVEs in four months, and counting). Third-party skills that run arbitrary code inside your agent. 800+ malicious skills found on ClawHub in a single audit.

And the stakes are different. Plex going down means someone can't watch a movie. Your AI agent going down means a client message goes unanswered for nine hours. The data inside it isn't your media library. It's documents, API keys, conversation history. Potentially client data.

The operational weight is structurally heavier than most self-hosted software. That's not a temporary problem. That's the nature of what this software does.

When Self-Hosting Is Still the Right Call

If you're learning how AI agents work under the hood, self-host. It's the best way to understand what's actually happening. If you need to modify the runtime itself, self-host. If infrastructure is your hobby and your homelab is where you unwind on weekends, self-host and enjoy it. If you already have an ops team managing servers, the marginal cost of one more container is low.

For all of those cases, Hetzner at ~$9/mo is hard to beat. OVH's free backups are a nice touch. Go for it.

When It Isn't

If infrastructure time is a cost, not recreation, the math is hard to argue with.

The VPS costs $9-56. Your time costs $400. The total is $409-448/mo, and it doesn't matter which provider you pick because your time dwarfs the infrastructure line.

I built Vessel because I didn't want to be the one reading that Monday notification. Dedicated GCP VM, Cloudflare Tunnel, patches and security hardening applied. Your time costs more than that.

220,000+ OpenClaw Instances Are Exposed. Here's How to Check Yours.

Mehul Bhardwaj — Sat, 28 Mar 2026 12:15:18 +0000

Security researchers have been scanning for exposed OpenClaw instances since January 2026. The numbers vary by methodology: Penligent found over 220,000, SecurityScorecard identified 135,000, Censys tracked growth from 1,000 to 21,000+ in a single week. Microsoft's security blog concluded that "for most environments, the appropriate decision may be not to deploy it."

Most of these instances are running without TLS. Many are still vulnerable to ClawJacked (CVE-2026-25253, CVSS 8.8), which allowed any webpage you visited to silently brute-force the gateway token over localhost with no rate limiting.

I've been reviewing public configs and deployment guides. Three misconfigs show up in the majority of them, and they're all fixable in minutes.

The exposure surface

OpenClaw's default config binds the gateway to 0.0.0.0:18789. If you install it on a VPS and don't touch the network settings, the gateway is public. There's no warning during setup. The docs mention it, but not where people look.

What this means in practice:

Gateway token brute-force. ClawJacked (CVE-2026-25253, CVSS 8.8) allowed any webpage you visited to brute-force the gateway token. No rate limiting. No CORS. Patched in v2026.1.24-1, but the fix requires updating. Persistent services that nobody actively maintains tend to drift.
Unencrypted traffic. Without TLS, everything between the browser and the agent travels in plaintext. API keys, model responses, user data. On a shared network, that's trivial to intercept.
Supply chain. ClawHavoc in January 2026: researchers found 824 malicious skills on ClawHub out of roughly 10,700 total. Clawdex, the main community scanner, was catching under 10% of them (Oathe's independent audit confirmed this). If your instance auto-installs recommended skills, you're trusting a supply chain that has already been compromised.

The three configs most people get wrong

I've reviewed hundreds of openclaw.json files from public repos, Docker Compose setups, and deployment guides. Three misconfigs show up in the majority of them.

1. Gateway binding

Default: binds to all interfaces (0.0.0.0:18789)
What it should be: loopback (127.0.0.1 only)

If you're running behind a reverse proxy or tunnel, the gateway should never be reachable directly. The bind key accepts loopback, lan, tailnet, or custom.

{
  "gateway": {
    "bind": "loopback",
    "port": 18789
  }
}

2. The three proxy/tunnel flags

If you're running behind a reverse proxy or Cloudflare Tunnel, you need three flags under gateway.controlUi. Not at the root level. Not as dot-notation keys. Nested JSON only.

{
  "gateway": {
    "controlUi": {
      "dangerouslyDisableDeviceAuth": true,
      "dangerouslyAllowHostHeaderOriginFallback": true,
      "allowInsecureAuth": true
    }
  }
}

Most guides mention two of these. The third, dangerouslyDisableDeviceAuth, is the one that causes the disconnected (1000): no reason error in the browser. It disables CLI-based device pairing, which only works with local machine access. Behind a proxy, there's no local CLI, so the auth loop times out silently.

The flag names sound dangerous. They're not, if you have a proxy handling auth in front. Without a proxy, don't set them.

3. TLS termination

If your reverse proxy handles TLS (it should), the gateway can run without its own certificate. But the connection between proxy and gateway must stay on loopback. If the proxy runs on a different host than the gateway, you need TLS on both hops.

[Browser] →HTTPS→ [Proxy (TLS)] →HTTP→ [Gateway (127.0.0.1:18789)]

This only works when proxy and gateway share the same host. Most single-VPS setups qualify.

How to check yours

Run these checks on any instance:

1. Port exposure check:

# From outside your network
nmap -p 18789 your-server-ip
# If it shows "open", your gateway is public

2. Config audit:

# On the server
cat ~/.openclaw/openclaw.json | grep -E "bind|dangerously|allowInsecure"

3. Version check:

openclaw --version
# Anything before v2026.1.24-1 is vulnerable to ClawJacked

I also built a free scanner that runs these checks and a few more (skill supply chain, known CVE patterns, config analysis): https://vesselofone.com/tools/security-check. It runs against your instance URL and returns a report. No data stored, no signup required.

TL;DR

Set gateway.bind to "loopback", not the default (all interfaces)
Set the three gateway.controlUi flags if behind a proxy or tunnel
TLS terminate at the proxy, keep gateway on loopback
Update to v2026.1.24-1 or later (ClawJacked fix)
Audit installed skills (ClawHavoc found 824 malicious ones on ClawHub)
Run a port scan from outside your network to verify nothing is exposed

Most of these take five minutes. The gap between "it works" and "it's not actively exploitable" is three config lines.