DEV Community: Mehul Bhardwaj

We Classified 16,635 OpenClaw Skill Complaints. Wrong Output Is the #1 Failure Mode.

Mehul Bhardwaj — Wed, 06 May 2026 07:58:44 +0000

The OpenClaw registry tracks whether skills install. The dominant user complaint is not installation failure. It is a skill that installs cleanly, runs without error, and produces wrong or missing output, with no signal that anything went wrong.

We classified 16,635 user mentions to find out what actually breaks.

How We Built the Dataset

Three sources:

GitHub Issues: scraped across openclaw/openclaw, openclaw/skills, and NVIDIA/NemoClaw via the GitHub Issues API
Hacker News: 16,840 raw mentions via the Algolia API, filtered to 54.7% noise (keyword collisions unrelated to the skills ecosystem)
Reddit: across 12 subreddits where OpenClaw skills discussions appear

Each mention was classified into one of 12 categories using Claude Haiku 4.5 with an enum-constrained schema. We validated a 500-item sample against Claude Sonnet 4.6. Exact agreement: 73.8%, κ = 0.71. Zero operational-versus-security confusions in the validation set.

The methodology, prompt, and validation data are published at vesselofone.com/research/ai-agent-skills-ecosystem. The full dataset is at doi.org/10.5281/zenodo.19691714 under CC BY 4.0. Reproducing the full classification pipeline requires an Anthropic API key and runs in approximately two hours at $10-30 in API cost.

What People Actually Complain About

Aggregated across all three sources:

Category	Share of all mentions
Operational correctness failures	20.7%
Silent failures (wrong output, no error)	18.4%
Compatibility problems	9.0%
Installation issues	7.3%
Security concerns	1.4% (GitHub) / 5.1% (Hacker News)
Discovery friction	1.7% (GitHub) / 8.3% (Reddit)

The top two categories together (39.1% of all classified mentions) describe the same underlying failure: a skill that appears to work but does not. The agent returns a result. The result is wrong. No error is raised. The user has to notice on their own.

Installation is 7.3%. It is the failure mode that gets the most tooling attention and causes the fewest complaints.

What You Find Depends on Where You Look

The three sources surface different problems. This is not sampling noise; it reflects how each platform is used.

GitHub skews toward operational correctness. Developers who encounter wrong output file detailed bug reports: reproduction steps, expected versus actual output, version numbers. 55.5% of GitHub-filed complaints describe correctness failures of this kind. These are the most actionable reports, but they require the user to know the output was wrong.

Hacker News surfaces security at 5.1% versus 1.4% on GitHub. Security researchers and people following incident reports congregate there. Discussions of supply-chain attacks and OAuth over-scoping appear in HN threads well before they produce GitHub issues.

Reddit surfaces discovery friction at 8.3% versus 1.7% on GitHub. Finding the right skill in a catalog of 6,993 is a genuine problem that never produces a bug report. Users who cannot find what they need leave a subreddit comment, not a GitHub issue.

If you only read GitHub Issues, you miss the security risk distribution and the discovery problem entirely.

Why the Security Numbers Understate Actual Risk

Security complaints represent 1.4% of GitHub mentions. That figure almost certainly understates actual exposure.

A successful supply-chain attack is silent by design. Users whose agents were compromised by the ClawHavoc campaign (skills that installed cleanly, ran without errors, and exfiltrated data through the agent's normal output channel) are not in this dataset. They do not know they were compromised. They filed no issues.

The 1.4% counts users who recognized a security problem and filed a report. It does not count users who were affected.

What This Means for Skill Authors and Installers

The dominant failure mode (silent wrong output) has no automatic detection. No error is raised. No alert fires. The skill appears healthy by every operational metric.

For skill authors: return explicit errors on unexpected input rather than plausible-looking wrong output. A skill that fails loudly is easier to debug than one that succeeds silently with bad results. Write correctness tests against representative data before publishing.

For installers: test skills with representative inputs before putting them in any workflow that touches real data. Monitor outputs, not just uptime. A skill that returns something is not the same as a skill that returns the right thing.

Full methodology and dataset: vesselofone.com/research/ai-agent-skills-ecosystem. Dataset at doi.org/10.5281/zenodo.19691714. Scan scripts at github.com/vesselofone/openclaw-skills under MIT + CC BY 4.0.

A free per-skill auditor covering SKILL.md intent, OAuth scope width, and injection patterns: vesselofone.com/tools/skill-check.

Vessel is managed OpenClaw hosting on private Linux VMs. Every agent we provision runs the skill auditor at setup. The research and dataset are open source.

70% of OpenClaw Skills Request OAuth Scopes They Don't Need

Mehul Bhardwaj — Fri, 01 May 2026 17:50:10 +0000

We ran two independent security scans across all 6,993 public skills in openclaw/skills. The dominant finding in both: skills routinely request OAuth permissions beyond what their stated task requires.

What the Scans Found

Snyk ToxicSkills (published static analysis):

Finding	Share of catalog
OAuth scopes wider than task requires	70.1%
Critical severity issues	13.4%

Vessel first-party scan (full catalog, reproducible, open scripts):

Finding	Share of catalog
Flagged dangerous	9.2%
Caution-level risk patterns	43.4%

These are different scans with different methodologies. They are not additive. Both are reproducible: the Snyk findings are published, and the first-party scan scripts and dataset are open source at github.com/vesselofone/openclaw-skills.

Over-scoping is the pattern that stands out. A skill that summarizes meeting notes should not hold a write token for your calendar. A skill that reads Slack channels should not have permission to post. In both scans, the majority of audited skills hold permissions beyond what they need for the described job.

OAuth grants persist after installation. The agent holds the token until you explicitly revoke it. Skills can be updated by their authors without notifying installers. The OAuth scope declared in version 1.0 may not be the same as in version 1.4.

What Hash Scanning Cannot Detect

Public reports placed the ClawHavoc campaign (malicious skills distributed through ClawHub) at between 341 and 824 skills. ClawHub responded by adding VirusTotal hash scanning. That response addresses one attack vector. It cannot address the primary one.

The attack surface in an OpenClaw skill is not executable code. It is the SKILL.md body: natural language that the agent reads and acts on. An adversarially crafted SKILL.md instructs the agent to exfiltrate data, establish persistence, or escalate access through the conversational interface. There is no binary to hash. ClawHavoc skills installed cleanly, returned clean VirusTotal results, ran without errors, and exfiltrated through the agent's normal output channel.

Hash scanning catches reused malicious binaries. It cannot detect adversarial natural language in the skill description. That surface remains uncovered.

What to Do Before Installing Any Skill

Read the full SKILL.md. Check what OAuth scopes it requests. Verify each scope is necessary for the stated task. Not just plausible: actually required.
Run a static check on the SKILL.md body for injection patterns and scope justification. The free auditor at vesselofone.com/tools/skill-check covers this. Paste a slug or repo URL.
Test with non-sensitive data before connecting production credentials or real client files.
Set a review reminder for six months. Skill authors can update SKILL.md without notifying installers.

Four Predictions (2026-2028)

Per-skill runtime correctness monitoring becomes a commercial product. Static analysis catches code risk but cannot evaluate whether a skill produces correct output at runtime. That monitoring layer does not exist yet as a product.
Another named supply-chain incident affects more than 100 skills. ClawHavoc established the playbook. Hash scanning did not close the attack vector. The adversarial NL surface in SKILL.md bodies is still fully open.
Enterprise procurement begins requiring security attestations for skills used in business workflows. Legal and financial teams running agents on client data will not accept installability as a quality standard.
Registries add evaluation requirements for marketplace inclusion. Pure installability metrics will not survive the first major enterprise procurement cycle.

Vessel is managed OpenClaw hosting on private Linux VMs. Every agent we provision runs the skill auditor at setup. The research and dataset are open source.

One apt Command Covers 97% of OpenClaw Skills on Linux. Here's the Full Map.

Mehul Bhardwaj — Wed, 29 Apr 2026 07:03:08 +0000

Most OpenClaw community documentation assumes a Mac. Setup guides use Homebrew. Sample skills shell out to pbpaste and osascript. The registry does not warn you when a skill declares a macOS-only binary. You install it, it runs, and it returns nothing useful the first time it hits pbpaste on a server.

To find out how deep that problem goes, we scanned all 6,993 public skills in openclaw/skills, parsed each SKILL.md, and resolved every declared binary dependency against a verified Linux install map. One apt line covers 6,784 of 6,993 skills: 97.0% of the catalog. The remaining 3% splits into pip-installable tools, curl install scripts, and about 10 skills that genuinely cannot run on Linux.

The line

sudo apt install python3 python3-pip nodejs npm curl jq git ffmpeg sqlite3 openssl ripgrep

No Homebrew. No uv. No Docker. No language managers. The Debian/Ubuntu package manager you already have.

This covers Ubuntu 22.04, Ubuntu 24.04, and Debian 12 (bookworm) completely. On Alpine, Arch, or RHEL, translate the package names. The set is the same.

82.6% of skills declare zero binary dependencies. They need nothing beyond Python and Node, which the apt line covers. The top declared dependencies across the 1,216 skills that do declare binaries:

Binary	Skills	Install
`python3`	536	`apt install python3`
`curl`	313	`apt install curl`
`node`	178	`apt install nodejs`
`jq`	78	`apt install jq`
`python`	45	symlink to `python3`
`npx`	32	ships with `nodejs`
`bash`	30	preinstalled
`npm`	28	`apt install npm`
`git`	21	`apt install git`
`ffmpeg`	19	`apt install ffmpeg`

Everything at the head of this list is preinstalled or one apt away.

Beyond the apt line

About 3% of the catalog declares a binary the apt line does not cover. That tail breaks into three groups.

Pip-installable tools: yt-dlp, pipx, uv, poetry, ruff. One pip install each. Already covered if you included python3-pip in the apt line.

Curl install scripts: uv, bun, Foundry's cast:

curl -LsSf https://astral.sh/uv/install.sh | sh    # uv + uvx
curl -fsSL https://bun.sh/install | bash           # bun
curl -L https://foundry.paradigm.xyz | bash        # cast + Ethereum tooling

Direct downloads: gh (GitHub CLI) and mcporter. Standard release tarballs from their respective repos.

Once you subtract these, the genuine residual is small: about 10 skills that cannot run on Linux regardless of what you install.

What you cannot get on Linux

Four skills require macOS desktop applications and have no equivalent in the catalog.

Desktop automation (AppleScript/osascript):

Airfoil (2,096 installs): controls AirPlay speakers. Requires the Airfoil macOS app.
Photoshop Automator (1,123 installs): runs Adobe Photoshop ExtendScript on a Mac.
Nerve Bridge Skill (591 installs): controls the Trae macOS app via AppleScript.
wallpaper-auto-switch-pro-executable (249 installs): switches macOS wallpaper via osascript and launchd.

Six more skills use pbpaste to read clipboard input. The clipboard mechanism is Mac-specific; the underlying capability is not. Each has a named replacement in the catalog that covers the same task with file input.

Mac skill	Installs	Linux replacement	Notes
`reply-coach`	280	`copy-editing`	File-based text rewrite
`reviewer-rebuttal-coach`	255	`copy-editing`	Swap pbpaste for file input
`collab-offer-polisher`	253	`medical-email-polisher`	Closest match for polishing business messages
`policy-to-checklist`	248	`afrexai-qa-test-plan`	Document-to-checklist generator
`claim-risk-auditor`	244	`verify-claims`	Direct claim/fact-check equivalent
`rubric-gap-analyzer`	244	`afrexai-interview-architect`	Rubric-based scoring, file input

That is the entire genuine residual. The broader set of 241 skills blocked by the apt line spans capabilities like Ethereum tooling, browser automation, video processing, and calendar sync. Every one of those categories has Linux-native alternatives in the same catalog. The live browser at vesselofone.com/skills/openclaw lets you filter by capability and find them.

TL;DR

One apt line covers 6,784 of 6,993 public OpenClaw skills on Linux (97.0%): sudo apt install python3 python3-pip nodejs npm curl jq git ffmpeg sqlite3 openssl ripgrep
82.6% of skills declare zero binary dependencies. They need nothing beyond what the apt line provides.
The remaining ~3% splits into pip-installable tools, curl install scripts, and 10 Mac-only skills.
4 skills require macOS desktop apps (Airfoil, Photoshop Automator, Nerve Bridge Skill, wallpaper switcher) and have no Linux equivalent. 6 pbpaste skills have named Linux replacements in the catalog.
The scan script is open source and reruns against the live catalog in about five minutes.

Installing is not the same as working

Knowing that 97% of skills resolve their binary dependencies on Linux is useful before you spend time setting up an agent. It does not tell you whether those skills produce correct output, or what security risks they carry. The full research (security scan and classified user complaint data alongside this installability view) is at vesselofone.com/research/ai-agent-skills-ecosystem.

Per-skill dataset (CSV, CC BY 4.0): doi.org/10.5281/zenodo.19691714. Scan scripts (MIT): github.com/vesselofone/openclaw-skills. The catalog scan reruns in about five minutes.

A free per-skill auditor covering SKILL.md intent, OAuth scope width, and shell-command injection patterns: vesselofone.com/tools/skill-check.

Vessel is managed OpenClaw hosting on private Linux VMs. We run the apt line above at provision time on every agent, so skills work on the first invocation. The scan script and dataset are open source.

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.