OpenClaw.NET: a self-hosted .NET agent runtime and gateway

What OpenClaw.NET is for

OpenClaw.NET is an independent .NET implementation of an agent runtime and gateway, inspired by the OpenClaw project but not affiliated with it. The README states that disclaimer directly, which matters because the two projects share a name and nothing else. The audience is narrow and stated: .NET developers and operators who want a local or self-hosted agent gateway with explicit diagnostics, first-party .NET tools, OpenAI-compatible HTTP surfaces, and a path from source checkout to NativeAOT release artifacts.

The problem it addresses is the gap between a chat wrapper and something you can operate. A runtime that executes tools, streams output, retries, keeps session and memory state, and exposes health and diagnostics is a different piece of software from a script that calls a model API. OpenClaw.NET bundles those pieces into one gateway process. It also ships channel adapters for Telegram, SMS, WhatsApp, Teams, Slack, Discord, Signal, Feishu, DingTalk, WeCom, email and webhooks, so the same runtime can be reached from messaging surfaces rather than only a browser tab.

If you are not on .NET, the fit is poor. The value here is the C# implementation, the NativeAOT publishing path, and reuse of existing OpenClaw TS/JS plugins and SKILL.md packages. A Python or Node team gets none of that and pays the cost of running a .NET stack.

How the runtime, gateway and harness fit together

The repository splits into src/OpenClaw.Core, src/OpenClaw.Agent, src/OpenClaw.Channels, src/OpenClaw.Gateway, plus adapters such as src/OpenClaw.MicrosoftAgentFrameworkAdapter and protocol projects like src/OpenClaw.Protocols.Browser and src/OpenClaw.Protocols.Mqtt. That layout tells you the shape: a core library, an agent loop, channel adapters, and a gateway that hosts HTTP surfaces and a chat UI.

Data flow is conventional for this class of tool. A request arrives at the gateway, the agent runtime assembles context from session and memory stores, calls a configured LLM provider, and executes tool calls. Native LLM providers listed in the README are OpenAI, Claude, Gemini, Azure OpenAI, DeepSeek, Ollama and OpenAI-compatible endpoints. Tool execution supports streaming, cancellation and retry. Output from verbose tools can be compressed before it enters model context through TokenJuice, described as deterministic, rule-driven compression.

The harness layer is the part worth reading twice. Harness Contracts, Evidence Bundles and the Governance Ledger are all described as passive: they produce inspectable plans, run evidence and approval records without intercepting default chat or approval behavior. Plan-Execute-Verify is optional and is the mode that actually governs high-risk tool execution. So the default runtime does not block a tool call because a contract exists; you opt into that. The README is explicit that the Governance Ledger does not auto-approve future actions. Teams expecting the harness to enforce policy out of the box will be surprised.

Installing OpenClaw.NET and running a first session

The lowest-friction path in the README is the desktop bundle. Prebuilt archives exist for Windows x64, Apple Silicon macOS and Linux x64, each containing Companion, the NativeAOT gateway and the NativeAOT CLI. The README gives three steps: extract the archive, launch Companion from the companion folder, and open it. There is no Intel macOS bundle listed.

For a server deployment, the repository ships a docker-compose.yml that builds from the Dockerfile. Two environment variables are required, and compose will refuse to start without them. MODEL_PROVIDER_KEY holds your LLM API key, and OPENCLAW_AUTH_TOKEN is required for any non-loopback bind. The compose file reads both from the shell environment:

environment:
  - MODEL_PROVIDER_KEY=${MODEL_PROVIDER_KEY:?Set MODEL_PROVIDER_KEY}
  - OPENCLAW_AUTH_TOKEN=${OPENCLAW_AUTH_TOKEN:?Set OPENCLAW_AUTH_TOKEN}
  - MODEL_PROVIDER_MODEL=${OPENCLAW_MODEL:-gpt-4o}

The gateway listens on port 18789, mapped as 18789:18789. The compose file sets OpenClaw__BindAddress=0.0.0.0 and OpenClaw__Port=18789, and defaults the provider model to gpt-4o through MODEL_PROVIDER_MODEL unless OPENCLAW_MODEL overrides it. Two safety defaults are worth noticing before you change anything:

environment:
  - OpenClaw__Tooling__AllowShell=false
  - OpenClaw__Tooling__AllowedReadRoots__0=/app/workspace
  - OpenClaw__Tooling__AllowedWriteRoots__0=/app/workspace
  - OpenClaw__Plugins__Enabled=false

Shell execution is off, file tools are confined to /app/workspace, and the JS plugin bridge is disabled for public binds. Memory and session data persist in the openclaw-memory volume mounted at /app/memory. The healthcheck runs /app/OpenClaw.Gateway --health-check every 30 seconds with a 10 second start period. An optional Caddy service is included for automatic TLS on port 443. The README points at docs/QUICKSTART.md as the supported local setup path, and docs/START_HERE.md as the evaluator overview.

Constraints you should decide about before deploying

The plugin story is the clearest limitation. The README badge reads plugin compatibility evolving, and the project describes practical reuse of existing OpenClaw TS/JS plugins rather than a frozen contract. If your architecture depends on a plugin API that will not move, that is a real risk. The compose file disables the plugin bridge by default for public binds, so you are expected to make an explicit decision to turn it on.

Shell access is the second. OpenClaw__Tooling__AllowShell=false is the shipped default, and the README does not document a sandbox around shell execution when you enable it. Turning it on in a container that mounts a host workspace changes the blast radius considerably. The same applies to AllowedReadRoots and AllowedWriteRoots: they default to /app/workspace, and widening them is a deliberate act.

Third, the documentation surface is split. The README points to AgentQi.dev for quickstart, architecture, security and roadmap, and notes that AgentQiX is the likely future runtime identity while OpenClaw.NET remains the current runtime and repository identity. That is an honest statement, but it means long-lived operational docs may follow a different name than the repository you cloned. The README does not document rollback for the desktop bundles or a downgrade path between releases; the release list shows v0.2.0, v0.1.4 and v0.1.3 with no migration notes in the README.

Finally, this is not the right tool if you want a managed service. Everything here assumes you run the gateway, hold the API key, and handle the network exposure yourself.

OpenClaw.NET compared with Microsoft Agent Framework

The most useful comparison is with Microsoft Agent Framework, because OpenClaw.NET ships a first-class optional adapter for it. Setting Runtime.Orchestrator=maf routes orchestration through MAF without a special build, and durable workflow delegation is available through backends such as maf-durable-http.

The difference in approach is scope. MAF is an orchestration framework: you compose agents, workflows and durable execution inside your own application, and you own the hosting, the endpoints, the channel integrations and the operational surface. OpenClaw.NET is a runtime plus a gateway: it already provides the HTTP surfaces, the chat UI, the admin UI, MCP, websocket, health and diagnostics, and the channel adapters. If you want to embed agent orchestration in an existing .NET service, MAF alone is the smaller dependency. If you want a running gateway with a chat UI, tool execution and messaging channels that you configure rather than build, OpenClaw.NET is the shorter path, and you can still delegate orchestration to MAF through the adapter.

Licence, releases and what upgrades cost

The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the whole of the licence implication here; whether your distribution satisfies the notice requirement is a question for your own counsel, not something this article can settle.

The release cadence visible in the release list is roughly monthly: v0.1.3 on 2026-07-01, v0.1.4 on 2026-08-06, v0.2.0 on 2026-09-10. The last push to the repository was on 2026-09-10. The version numbering suggests pre-1.0, so breaking changes between minor versions are a reasonable expectation, though the README does not state a compatibility policy. The CHANGELOG.md at the repository root is where release notes live; the README does not summarise them.

Upgrade cost depends on your deployment shape. Desktop bundles are replaced wholesale, so the cost is re-extracting and reconfiguring. Docker deployments rebuild from the Dockerfile, which compiles a NativeAOT binary and installs clang and zlib1g-dev in the build stage, so build times are longer than a typical .NET image. Memory and session data live in the openclaw-memory volume and are not part of the image, which keeps upgrades from discarding state. The compose file also pins the image via OPENCLAW_IMAGE, defaulting to openclaw.net:local, so you control when a new build is picked up.

Editorial conclusion

Adopt OpenClaw.NET if you are a .NET developer or operator who wants an agent gateway you run yourself, with OpenAI-compatible HTTP surfaces, native tool execution and channel adapters, and you are comfortable reading docs/START_HERE.md and docs/QUICKSTART.md before deploying. Do not adopt it if you need a stable plugin contract: the README labels plugin compatibility as evolving, and the desktop bundle is the only path with prebuilt binaries. Verify first that your target platform has a desktop bundle or that you can build the NativeAOT image from the Dockerfile, that you have set OPENCLAW_AUTH_TOKEN before binding beyond loopback, and that OpenClaw__Tooling__AllowShell stays false unless you have decided you want shell execution.

Frequently asked questions

Official sources

1. clawdotnet/openclaw.net on GitHub
2. License: MIT
3. Project website
4. README
5. Releases