OpenClaw with Claude on macOS and Windows: Features, Risks and the Real Control Plane

OpenClaw is one of the most capable personal AI agents you can run today. It is also one of the easiest to get wrong. This post covers what it does when paired with Claude, where the security gaps are, and which settings actually control what it can and cannot do. It closes with how OpenClaw compares to Hermes Agent and Microsoft Scout, and which AI subscriptions each one can use.

How OpenClaw and Claude fit together

OpenClaw is not a Claude product. It is an open-source, self-hosted agent runtime. Claude is one of many models it can use for reasoning.

The split matters for security:

• Claude decides what to do.
• OpenClaw does it: shell commands, file access, browser control, messaging, camera and screen capture.

Almost all of the risk lives on the OpenClaw side.

Using Claude with OpenClaw in 2026

• Since 4 April 2026, Claude Pro and Max subscriptions no longer cover third-party agent frameworks such as OpenClaw. You need Anthropic's pay-as-you-go extra usage or a separate API key billed at standard API rates.
• OpenClaw's creator joined OpenAI in February 2026. The project now runs under the OpenClaw Foundation.
• Anthropic's own option, Claude Code Channels, launched in March 2026 with Telegram and Discord. OpenClaw still covers more channels, including WhatsApp, iMessage, Slack, Signal and Microsoft Teams.

What it does on each platform

macOS

• A menu bar companion app manages system permission prompts (Accessibility, Screen Recording, Microphone, Notifications).
• The Mac registers as a "node" the agent can control: camera snapshots and clips, screen snapshots and recording, notifications and system.run for shell commands.
• The gateway runs as a per-user LaunchAgent.
• The app registers an openclaw:// URL scheme for local actions.
• Native extras include iMessage, FaceTime, voice wake and Apple Foundation Models.

Windows

• Windows Hub is a native WinUI companion app for Windows 10 20H2+ and Windows 11.
• It can set up and manage a gateway inside WSL for you.
• In node mode the PC exposes screen capture, camera, notifications, device status, text-to-speech, speech-to-text and controlled system.run.
• Some older guides say Windows has no native app. That is no longer true.

Both platforms

• One always-on agent reachable from around 40 chat channels.
• Persistent memory, scheduled automations and a heartbeat loop.
• Sub-agents and multi-agent routing.
• Browser control, web search and fetch.
• MCP server support.
• Skills and plugins from the ClawHub marketplace.
• Triggers from Gmail, IMAP and inbound webhooks.

Why people use it

• You can message one agent from any phone app and have it act on your own machines.
• It is model-agnostic, with failover between providers.
• You own the data, the config and the runtime. It can run fully local.
• Configuration is policy as code, with a built-in security audit command.

Threat vectors seen in the wild

These are not theoretical. Each one has been documented in 2026.

1. Exposed gateways. JFrog reported that 93.4% of publicly reachable OpenClaw instances had critical authentication bypass issues.
2. One-click remote code execution. CVE-2026-25253 abused a WebSocket origin check. Visiting a malicious web page was enough to steal tokens and gain operator-level gateway access. Some write-ups wrongly label this CVE as the ClawHub supply chain attack.
3. Malicious skills. The ClawHavoc campaign planted 341 malicious skills on ClawHub, growing to more than 824 as the marketplace expanded. Snyk found security flaws in 36% of the 3,984 skills it audited.
4. Fake installers. A malicious npm package posed as the OpenClaw installer, and fake GitHub releases shipped infostealer malware.
5. Prompt injection through content. Locking down who can message the bot is not enough. Any web page, email, document, attachment or pasted log the agent reads can carry hostile instructions.
6. Hidden prompt swap. A bundled hook called soul-evil could silently replace the agent's core system prompt with an alternate file.

Gaps by design

These come from OpenClaw's own trust model. They are deliberate choices, so do not expect patches.

• One trust boundary per gateway. OpenClaw is not built for users who don't trust each other to share an agent. Anyone who can message a tool-enabled agent shares its full tool authority.
• Host exec without prompts by default. For a trusted single operator, the default is security="full" and ask="off". Out of the box, the agent can run shell commands on your host without asking.
• Open session visibility. tools.sessions.visibility defaults to all and agent-to-agent messaging is on. Any unsandboxed tool-enabled agent can read every other agent's transcripts.
• Exec approvals are not isolation. They check operator intent. They do not model every interpreter or loader path. Strong boundaries need sandboxing and host isolation.
• Tool policy works by name only. It decides which tools exist. It does not inspect what a command does once exec is allowed.
• Sender checks don't clean the prompt. Per-sender controls apply to whoever triggered the turn. Quoted, forwarded or fetched content from someone else can still steer that turn.

The real control plane

Everything is governed by ~/.openclaw/openclaw.json. OpenClaw treats anyone who can modify that file as a trusted operator. Protect it like a root credential.

Controls stack in this order:

Layer	Config keys	What it controls
Identity	channels.*.dmPolicy, allowlists, requireMention	Who can talk to the agent
Gateway	gateway.bind, gateway.auth	Who can reach the control plane
Tool policy	tools.profile, tools.allow, tools.deny, per-agent and per-provider overrides	Which tools exist. This is the hard stop.
Exec	tools.exec.security, tools.exec.ask, tools.exec.strictInlineEval, app exec approvals	Which shell commands run
Sandbox	agents.defaults.sandbox.mode (Docker, Podman, SSH)	Where commands run
Elevated	tools.elevated.*	Escape hatch out of the sandbox
Nodes	gateway.nodes.allowCommands	Device capabilities such as camera and screen
Cross-agent	tools.sessions.visibility, tools.agentToAgent	How far agents can see and message each other

How the layers interact:

• Tool policy wins. Nothing, including elevated mode, can re-enable a denied tool.
• Elevated mode needs three gates to pass: a global switch, a sender allowlist and a per-agent switch.
• /elevated full skips exec approvals entirely. Keep tools.elevated.enabled: false unless you have a specific need.
• On macOS, system.run is gated by exec approvals in the companion app settings.
• On Windows, privacy-sensitive commands such as screen.record, camera.snap and camera.clip need an explicit gateway.nodes.allowCommands opt-in.

Hardening checklist

1. Start from the official hardened baseline. Bind to loopback, use token auth, set tools.profile: "messaging", deny automation, runtime and filesystem tool groups, set exec to security: "deny" with ask: "always", disable elevated, set session visibility to agent and turn agent-to-agent off. Re-enable tools one agent at a time.
2. Turn sandboxing on. It is opt-in. Without it, exec runs on the host.
3. Never expose the gateway to the internet. Use Tailscale or Cloudflare Access and follow the official exposure runbook.
4. Treat ClawHub as untrusted. Read a skill's source before installing it and pin versions.
5. Split reading from acting. Route untrusted content through a read-only reader agent. Keep web_search, web_fetch and browser off for agents that can run tools.
6. Leave bypass flags off. Keep allowUnsafeExternalContent disabled for hooks, Gmail and cron payloads.
7. Isolate the bot's identity. Use a dedicated phone number and dedicated accounts. Keep secrets out of any path the agent can read.
8. Isolate the host. Run OpenClaw under a separate OS user or in a VM, not your main profile.
9. Audit continuously. Run openclaw security audit --deep after every config change and every update.
10. Use a strong model for tool-enabled agents. Frontier models resist injection far better than small ones. Even so, adaptive human attackers still beat strong defences most of the time. Model choice is your first layer, not your fix.

Baseline config

From the OpenClaw hardened baseline documentation:

{
  gateway: {
    mode: "local",
    bind: "loopback",
    auth: { mode: "token", token: "replace-with-long-random-token" },
  },
  session: {
    dmScope: "per-channel-peer",
  },
  tools: {
    profile: "messaging",
    deny: ["group:automation", "group:runtime", "group:fs", "sessions_spawn", "sessions_send"],
    fs: { workspaceOnly: true },
    exec: { security: "deny", ask: "always" },
    elevated: { enabled: false },
    sessions: { visibility: "agent" },
    agentToAgent: { enabled: false },
  },
  channels: {
    whatsapp: { dmPolicy: "pairing", groups: { "*": { requireMention: true } } },
  },
}

Bottom line

OpenClaw gives Claude real hands on your machines. The defaults suit a single trusted operator, not a business environment. Lock identity first, then scope, and assume the model can be manipulated. Design so that a manipulated agent can only do limited damage. The same rules apply to Hermes Agent and any other self-hosted personal agent.

For the alternatives — Hermes Agent and Microsoft Scout — see our companion post, Personal Agents: Hermes Agent and Microsoft Scout.