What is OpenClaw? How self-hosted assistants, Gateways and chat channels work together
OpenClaw’s self-hosted assistant and persistent Gateway, with the roles of sessions, models, channels and trust boundaries rather than treating it as a model or IDE.
Meet this tool
OpenClaw is an AI assistant and coordination system run on infrastructure you control. A persistent Gateway connects chat channels, sessions and tools so users can start tasks from familiar messaging interfaces. The Gateway provides control and connectivity while models process task information. OpenClaw is not one fixed model, and self-hosting does not establish that all inference or data stays on the machine.
The Gateway connects chat channels with task sessions
For a project query through Telegram or WebChat, the channel sends the request to the Gateway and the relevant assistant. Channels provide interaction while the Gateway maintains connections and sessions. Configured tools determine actions; connecting a chat account does not automatically create file access or business-service permissions.
Unlike a simple model chat wrapper, OpenClaw also coordinates persistent sessions, tools and message delivery. It suits access to one assistant through multiple interfaces. Direct repository development may fit a dedicated coding tool without an additional messaging layer.
Sessions and memory preserve state across devices
Session state and memory provide continuing context but differ from source files. Old state may be stale and important conclusions need source checks. Accessing one assistant from another device does not automatically synchronize every device’s local files.
The Gateway is a persistent control plane, requiring process, storage, update and recovery planning. Self-hosting the assistant does not install model weights; external inference still calls a model service. Identify assistant-state storage separately from model-request destinations.
Configure models separately from tools and deployment
Providers perform inference while tools and plugins execute external actions. Replacing a model neither installs missing tools nor grants downstream authorization. Check tool-calling and context requirements; an endpoint answering chat does not establish the full assistant works.
OpenClaw coordinates assistants rather than aiming to replace every IDE. With Codex or Claude Code, distinguish message routing from the actual coding session. Sending a request is not completed editing. Persistent project work needs an explicit repository and execution environment.
A shared Gateway has an explicit trust boundary
A Gateway can serve a mutually trusted team, but its documented security model is not strong isolation between hostile users. Separate trust domains need separate Gateways and credentials and, where appropriate, OS users or hosts. Multi-user features do not make arbitrary mutually distrustful tenancy safe.
Sender identity, tool privileges and cross-channel messaging must match actual configuration. Group membership alone does not establish authorized assistant use. After installation or channel setup, inspect allowed identities and actions. Connection health establishes only part of the path; business resources must confirm outcomes.
Checked sources
These sources support the concepts and methods described here. Examples and test scope are labeled separately; check the version of the tools you use.