OpenClaw Self-Hosted Personal AI Gateway

OpenClaw is what happens when a personal AI assistant stops being a chat window and becomes infrastructure. It runs a gateway on hardware you control, connects that gateway to messaging channels, gives an agent tools, memory and scheduled work, and lets you choose which model supplies the intelligence. A message sent from Telegram, Slack, WhatsApp or another channel can become a real action on the host machine.

That makes OpenClaw unusually capable. It also makes it one of the clearest examples of why agent security cannot be treated as a settings page that users visit later. The official security documentation is direct: depending on policy, an assistant can execute shell commands, read and write files, access network services and send messages. If the wrong person can reach it, a prompt is misinterpreted or a connected tool returns malicious instructions, the result can affect real accounts and data.

OpenClaw should therefore be understood as a personal agent runtime for a trusted operator, not a hosted chatbot and not a safe multi-user boundary. The project gives technical users control over models, channels, sessions, permissions and deployment. That control is valuable, but it transfers operational responsibility to the person running the gateway.

What OpenClaw is in 2026

The current documentation describes OpenClaw as a self-hosted gateway connecting chat apps to AI coding agents. One Gateway process can serve several installed channel plugins, maintain sessions, route messages, call tools and coordinate multiple agents. The system is open source under the MIT license and developed publicly by the nonprofit OpenClaw Foundation.

The user experience can be deceptively simple. You message an assistant from a familiar app and receive a reply in the same place. Underneath, the gateway identifies the channel and sender, selects the correct agent and session, builds context, invokes a model, handles tool requests and routes the result back deterministically. The model does not casually choose where a reply goes; routing is controlled by host configuration.

Supported channels now extend well beyond the familiar early list. Official documentation includes Discord, Google Chat, iMessage, Matrix, Microsoft Teams, Signal, Slack, Telegram, WhatsApp and many others. Some ship in core, while others install as official or external plugins. Text works broadly, but media, reactions, group behavior and authentication differ by channel.

OpenClaw also supplies WebChat and a browser-based Control UI. Companion and node software can extend the assistant to desktop and mobile environments. The current installation guidance supports macOS, Linux and Windows, with several Windows paths including a signed Hub companion, PowerShell installation or a WSL2 gateway. The installer can provision a supported Node runtime when required.

The Gateway is the product

It is tempting to describe OpenClaw by a list of tasks: manage email, make reminders, create issues, browse pages or run scripts. Those examples change with installed plugins and permissions. The durable product is the coordination layer connecting a model to the user's channels, tools and persistent working context.

This is why OpenClaw can support very different assistants. One user might create a private coding coordinator that receives requests in Slack, opens GitHub issues and reports CI failures. Another might run a household assistant through WhatsApp. A third might operate several isolated agents, each with its own workspace, model, memory and sender routing.

Sessions are important because messaging channels do not naturally map to one clean conversation. Direct messages can share a main session or be separated by peer, channel and account. Groups and rooms can remain isolated. Threads in services such as Slack and Discord can have their own keys. Good routing prevents one person's context from leaking into another conversation and stops a group request from inheriting private personal history.

Multi-agent routing expands that idea. A message can be directed to an agent with a particular workspace and policy rather than one universal assistant. This allows a coding agent to have repository access while a general chat agent does not. It also limits the consequences of a mistake if each agent has separate credentials, tools and files.

Models are interchangeable, authority is not

OpenClaw supports a very wide provider directory. It can connect to Anthropic, OpenAI, Google, Amazon Bedrock, DeepSeek, Mistral, OpenRouter and many other hosted services. Local options include Ollama, LM Studio, llama.cpp, vLLM and OpenAI-compatible servers. Model fallback can rotate authentication profiles and move to configured backup models when a provider is unavailable.

This flexibility avoids locking the entire assistant to one model. A user can select a strong hosted model for complex tool use, a less expensive model for routine jobs and a local model for selected private tasks. OpenAI agent turns can use the native Codex app-server harness, while OpenClaw continues to own channels, memory, sessions, cron, media, browser and gateway tools.

Changing the model does not change the permissions already granted to the runtime. A smaller local model may keep prompts off a hosted model API, but it can be less reliable at following policy, recognizing prompt injection and maintaining long contexts. OpenClaw's local-model guidance explicitly warns that small or heavily quantized models can truncate context and lack provider-side safety filters.

Self-hosted also does not automatically mean offline or completely private. If the selected model is hosted, prompts and relevant context still travel to that provider. If the agent accesses Gmail, GitHub or another cloud service, data is exchanged with that service. Web search and browser actions contact external sites. The gateway may be local while the overall workflow remains distributed across several companies.

The correct privacy statement is more precise: OpenClaw lets the operator decide where the gateway, memory and tools run and which providers receive data. It does not guarantee that every connected workflow stays on one device.

Security is the central product question

OpenClaw's threat model begins with authority. A capable assistant may be able to run arbitrary commands, inspect files, use credentials and communicate externally. The most common failure is not a sophisticated exploit. It is an untrusted sender or piece of content persuading the agent to do something the operator did not intend.

Messaging access is therefore the first boundary. Direct-message senders should be allowlisted or paired deliberately. Groups are restricted by default and generally require mentions. A personal assistant should use a dedicated account or number where practical, rather than sharing an identity that receives unpredictable public messages.

Tool permissions are the second boundary. Shell access should not be global simply because one workflow needs a command. The agent should have a narrow workspace, separate credentials and an explicit command policy. Read-only tools are safer starting points than write-capable or administrative access. Sending messages, changing repository state, deleting files and modifying account permissions should require approval until the workflow is proven.

Sandboxing can move tool execution into an isolated backend and reduce the blast radius. The important detail is that it is off by default, and the Gateway process itself remains on the host. The documentation also says the sandbox is not a perfect security boundary. It is one layer in a design that still needs allowlists, least privilege, secret separation, logs and review.

OpenClaw has been developing more nuanced execution approvals. Its opt-in auto mode applies policy first, can send low-risk misses for review and routes uncertain commands back to a human. This is more useful than a binary choice between approving every harmless command and running everything in a no-approval mode. Because the project describes auto as a path being tested rather than a universal default, operators should verify the behavior of their installed release.

Skills and plugins change the trust boundary

OpenClaw distinguishes skills from plugins. A skill is primarily an instruction bundle teaching an agent how and when to use available tools. A plugin can add code, credentials, model providers, tools, channels, speech, hooks and other runtime capabilities. Both can be discovered through ClawHub, the public registry.

Skills can look safer because they are text, but instructions can still influence an agent to disclose data, call a risky tool or override the operator's intent. Plugins carry the additional risks of executable code, dependencies and credential access. Every installation expands the trusted computing base.

ClawHub provides security audits and trust signals intended to show requested authority and concerning behavior. The documentation is careful not to call an audit a guarantee. Users should inspect publisher identity, source repository, exact version, permissions, environment variables, credentials, changelog and audit findings before installation. Community content is not maintained or patched by OpenClaw simply because it appears in the registry.

OpenClaw's move to keep the core smaller and shift optional capabilities toward plugins is sensible for maintainability. It also makes package review a normal part of using the platform. Updates deserve the same scrutiny as first installs because a new version can add permissions or dependencies.

Reliability is still part of the story

The project has been candid about release problems. In May 2026, OpenClaw published an account of a difficult release period in which gateways slowed, plugin dependency repair loops appeared and several messaging channels became less reliable. Some users downgraded. The response was to make core smaller, move optional features to ClawHub and improve release discipline.

That transparency is valuable, but the incident is also a procurement signal. OpenClaw moves quickly and its ecosystem is broad. An update can affect channel delivery, authentication, plugin loading or scheduled work. Anyone relying on the gateway for important automation should pin known-good versions, test upgrades in a separate environment and maintain a rollback plan.

Long-term support releases can reduce churn, but users should verify current support policy rather than assuming every release is production-ready. Monitoring should cover gateway health, channel probes, failed sends, tool errors, model fallbacks and scheduled-job completion. A personal assistant that silently stops replying can be annoying. One that sends a message or runs a job twice can be costly.

What OpenClaw really costs

The core software is free and open source. There is no OpenClaw subscription required to run the gateway. That does not mean the assistant costs nothing. Most practical setups combine model access, hardware or hosting, messaging services and third-party APIs.

A user with an existing computer and a local model may avoid recurring model fees, but capable local inference can require substantial memory and power. Hosted models charge through subscriptions, API usage or provider-specific limits. A server that keeps the gateway available continuously adds hosting cost. SMS, voice, search, browser services and business APIs may bill separately.

The honest price range is therefore usage-based. OpenClaw does not impose one universal monthly plan because it does not control the external stack. Operators should monitor cost by provider, model, agent, scheduled job and tool. Model fallback is useful for uptime, but an expensive backup can turn a provider outage into an unexpected bill.

Caching, model routing and local inference can reduce cost, but optimization should come after observability. If a cron job enters a loop or a channel repeatedly retries, cheap tokens can still accumulate. Budgets and provider limits should be set outside the agent as well as described in prompts.

Who OpenClaw is best for

OpenClaw is best for developers and technical power users who want an assistant reachable from several devices and channels while retaining control of its gateway and configuration. It suits people willing to manage a service, inspect logs, review permissions and maintain integrations. It is especially interesting when durable memory and orchestration matter more than the fastest direct coding loop.

The official FAQ makes that distinction clearly. OpenClaw is not intended to replace an IDE. Claude Code or Codex may be faster for direct work inside a repository. OpenClaw is the coordination layer that makes an agent persistent, cross-device, proactive and available through messaging.

It can also fit small trusted teams if agents, workspaces and sender policies are designed carefully. It is not designed as a hostile multi-tenant boundary for unrelated users sharing one gateway. Organizations needing strong tenant isolation should use separate gateways or another architecture, not assume that session separation equals a formal security boundary.

OpenClaw is a poor fit for someone who wants a completely managed consumer assistant with no setup. Installation has improved, but channel pairing, provider authentication, plugins, security policy and ongoing updates still require judgment. It is also unsuitable for users who want to grant broad computer access once and never supervise the system.

A safe first deployment

Start on a dedicated test machine, user account, container or low-value server. Install from the official source and complete onboarding with one model. Use WebChat first so model and gateway behavior can be tested before adding an external messaging surface.

Create one agent with a separate workspace. Do not expose personal documents, SSH keys, password stores or production repositories. Enable sandboxing for tool execution where compatible. Use command allowlists and approval prompts. Keep outbound messages and file changes disabled until basic behavior is stable.

Add one private channel and approve only your sender identity. Test how direct messages, group mentions and threads map to sessions. Send adversarial prompts and malicious-looking document content to see whether the agent follows embedded instructions. Confirm that blocked senders and disallowed commands fail closed.

Choose one narrow automation, such as a daily summary from read-only sources. Log every tool call, model selection, fallback and result. Set a low provider budget. Let the job run repeatedly before expanding its schedule or scope.

Review every ClawHub skill or plugin before installation. Prefer official or verified sources, check audit findings and pin the exact version. Revisit permissions after updates. Maintain backups of configuration and memory, but protect those backups because they may contain credentials and sensitive context.

Only widen authority when the agent has demonstrated reliable behavior. Add file writes before shell administration, internal drafts before external messages, and reversible actions before destructive ones. Separate high-risk workflows into their own agent and gateway where practical.

The WhatAI view

OpenClaw is one of the most complete open-source attempts to make a personal AI assistant persistent and operational. Its value is not a novel chat interface. It is the gateway that connects channels, models, memory, tools, schedules and multiple agents under the operator's control.

The project's documentation also reflects a healthy realism about the danger. It tells users that agents can run commands and access data, says sandboxing is imperfect and off by default, describes the trusted-operator model, and publishes openly about release failures. That candor should not be interpreted as a reason to ignore risk. It is a reason to configure the system with the same care as any service holding credentials and remote execution authority.

OpenClaw is most compelling when control is paired with discipline. Self-host the gateway, but map every external provider. Enjoy multi-channel access, but restrict senders and isolate sessions. Install skills, but inspect their instructions. Install plugins, but treat them as code. Give the assistant tools, but make authority narrow, observable and revocable.

For the right operator, OpenClaw can become a durable layer between everyday messages and serious agent work. For everyone else, a managed assistant with fewer permissions may be the better product. The question is not whether OpenClaw can do more. It is whether you are prepared to operate what it can do.

WhatAI Decision Box

OpenClaw is an open-source gateway that connects AI agents to messaging channels, models, tools, memory and scheduled work. It runs on hardware you control and supports multiple isolated agents, local or hosted models and a growing extension registry.

A single Gateway receives messages from configured channels, routes them to an agent and session, invokes the selected model and handles permitted tool calls. Operators can add skills, plugins, model fallbacks, cron jobs, mobile nodes and access controls.

The core software is free, but models, hosting and connected services may cost money. OpenClaw can execute commands and access files, networks and messages, so operators need sender allowlists, narrow permissions, approvals, optional sandboxing and monitored updates.

Use Cases

Pricing varies by plan and region — see current pricing.

Plan features change — last updated: 2026-08-25.

OpenClaw Community Discussions

Explore community discussions. Ask and answer questions on OpenClaw to grow and learn together.

OpenClaw Pros & Cons

How to Get Results with OpenClaw: Step-by-Step Workflow

1. Choose an isolated host

   Start on a dedicated test machine, user account, container or low-value server without sensitive files or credentials.

2. Install from official sources

   Use the official installer or repository, complete onboarding with one model and verify the Gateway through WebChat.

3. Create one restricted agent

   Give it a separate workspace, minimal tools, a low provider budget and approval for every write-capable action.

4. Add one private channel

   Pair or allowlist only your sender identity and test how direct messages, groups and threads map to sessions.

5. Enable safety layers

   Configure command policy, sandboxing where compatible, secret separation, logs and human approval for uncertain commands.

6. Pilot one read-only job

   Run a narrow scheduled summary repeatedly and monitor tool calls, fallbacks, retries, failures and total cost.

7. Expand authority gradually

   Review every skill, plugin and update, then add reversible writes before messaging, destructive actions or administration.

OpenClaw Gotchas and Limits to Know Before You Start

• OpenClaw agents may execute shell commands, read and write files, access networks and send messages when permitted.
• Sandboxing is off by default and does not isolate the Gateway process itself.
• The sandbox reduces blast radius but is not documented as a perfect security boundary.
• Self-hosting does not keep data local when hosted models or connected cloud services are used.
• OpenClaw is designed for a trusted operator, not adversarial users sharing one Gateway.
• Untrusted messages, documents and web pages can attempt prompt injection against tool-enabled agents.
• Community skills can influence tool use, while plugins add executable code, dependencies and credentials.
• ClawHub audits are useful signals but not guarantees that a package is risk-free.
• Fast-moving releases can affect channel delivery, plugins, authentication and scheduled jobs.
• Operators need version pinning, test upgrades, backups and a rollback plan for important deployments.
• Model fallback can improve uptime but unexpectedly move work to a more expensive or different provider.
• Local models may have weaker tool reliability, smaller context and fewer provider-side safety controls.
• Core software is free, but model, hosting, messaging and API costs remain the operator's responsibility.

Which OpenClaw Feature Fits Your Use Case

Starter Prompts for OpenClaw

What is OpenClaw?

OpenClaw is an open-source, self-hosted gateway that connects messaging channels to AI agents with tools, sessions, memory, schedules and optional plugins.

Where does OpenClaw run?

The Gateway runs on hardware or a server controlled by the operator. Current installation paths support macOS, Linux and Windows, with desktop, browser and mobile companion surfaces.

Which chat applications does OpenClaw support?

Official documentation includes Discord, Google Chat, iMessage, Matrix, Microsoft Teams, Signal, Slack, Telegram, WhatsApp, WebChat and many additional channel plugins.

Which AI models can OpenClaw use?

OpenClaw supports a large provider directory including OpenAI, Anthropic, Gemini, Bedrock, OpenRouter and DeepSeek, plus local services such as Ollama, LM Studio, llama.cpp and vLLM.

Is OpenClaw free?

The MIT-licensed core software is free. Operators still pay for any hosted models, servers, hardware, messaging services and external APIs used by their setup.

Does self-hosting keep all data private?

Not automatically. The gateway and memory can stay on your hardware, but prompts or data may still reach selected model providers, messaging systems, websites and connected cloud services.

Is OpenClaw sandboxed by default?

No. Tool-execution sandboxing is available but off by default. The documentation says it reduces blast radius without being a perfect security boundary.

Is OpenClaw suitable for multiple untrusted users?

OpenClaw is designed for a trusted operator, not as a hostile multi-tenant security boundary. Separate gateways are safer when users should not trust one another.

What is the difference between skills and plugins?

Skills are instruction bundles teaching agents how to work with tools. Plugins can add executable code, credentials, channels, tools, providers and runtime behavior, so they require deeper review.

Related Agents & Automation Tools

Explore the Network