OpenClaw.NET: a self-hosted .NET agent runtime that ships its own gateway
Self-hosted Personal AI + agent runtime in .NET (NativeAOT-friendly)
At a glance
- What is it?
- OpenClaw.NET is an MIT-licensed C# agent runtime and HTTP gateway aimed at .NET developers who want to self-host. The README documents a wide feature surface, but also a plugin compatibility badge it calls evolving and an explicitly future runtime identity.
- Who is it for?
- Adopt OpenClaw.NET if you are a .NET team that wants an agent runtime, gateway, and CLI in one repository and can build from source or run the published desktop bundles. Do not adopt it if you need a stable plugin contract, because the README labels plugin compatibility as evolving and names AgentQiX as a likely future runtime identity, which implies a rename or migration later.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly C#, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap OpenClaw.NET fills for .NET shops
Most agent runtimes are distributed as Python or TypeScript packages, which means a .NET team either runs a second language runtime in production or wraps an external service. OpenClaw.NET takes the other route: the runtime, the HTTP gateway, the CLI, and the desktop companion are all C# and all live in one repository. The README describes it as "a NativeAOT-friendly AI agent runtime and gateway for .NET with practical OpenClaw ecosystem compatibility", and the NativeAOT angle is the part that matters operationally. A runtime that can be published ahead-of-time compiles to a native binary without a JIT, which changes what you have to install on a host.
The stated audience is narrow and honest about it: .NET developers and operators who want a local or self-hosted gateway with explicit diagnostics, first-party tools, and OpenAI-compatible HTTP surfaces. That last item is the integration hook. Because the gateway exposes OpenAI-compatible endpoints, existing clients that speak that protocol can point at your instance instead of a hosted provider. The repository also carries a disclaimer that it is not affiliated with the OpenClaw project, so the name signals inspiration rather than a fork relationship.
Runtime, gateway, and CLI as three separate binaries
The architecture visible in the README splits into a runtime and a gateway. The runtime handles tool execution, streaming, cancellation, retry, memory, and sessions. The gateway wraps that in a chat UI, an admin UI, OpenAI-compatible endpoints, MCP, websocket support, health checks, and diagnostics. The CLI is a third surface, and it is where the harness tooling lives.
That split matters because it determines where you put policy. Tool execution and memory sit in the runtime, so a tool you register is reachable from every channel the gateway exposes. The gateway is where channel adapters attach: Telegram, SMS, WhatsApp, Teams, Slack, Discord, Signal, Feishu, DingTalk, WeCom, email, and webhooks. The README notes that Feishu, DingTalk, and WeCom use sender and group allowlists over authenticated WebSocket connections, which is a per-channel access control rather than a global one.
Model access is also layered. Native providers are listed for OpenAI, Claude, Gemini, Azure OpenAI, DeepSeek, Ollama, and generic OpenAI-compatible endpoints. Separately, there is optional embedded local inference using Gemma 4 GGUF packages, installed and verified through CLI commands and run as a supervised sidecar. Those are two different deployment shapes: remote API calls versus a local process the runtime supervises.
Harness contracts, evidence bundles, and the passive default
The most distinctive part of the README is the harness vocabulary, and the word doing the work is passive. Passive Harness Contracts produce inspectable agent-work plans without changing default chat or approval behavior. Passive Evidence Bundles collect run evidence, checks, risks, and human review without default runtime interception. The Passive Governance Ledger records approval and oversight decisions but, per the README, does not auto-approve future actions.
Read together, those three describe an observability layer that records what happened and what was planned, while leaving the execution path untouched unless you opt in. The opt-in is Plan-Execute-Verify mode, described as optional and intended for governed high-risk tool execution with contracts, evidence, and verification. So the design gives you a record by default and enforcement only on request.
There is a supporting toolchain around it. `openclaw harness test` runs an offline regression suite before you trust harness or runtime changes. `openclaw harness map` produces a passive static map of a repository covering projects, modules, endpoints, tools, providers, channels, config, and tests. Harness Evolution Proposals are described as review-first suggestions for changing harness policies, routing, memory retrieval, verification, and tool governance. Every one of those is review-first or offline, which is a consistent posture: the system proposes, a human disposes.
Getting a local instance running
Two setup paths are documented. The lowest-friction one is the desktop bundle. Releases publish `openclaw-desktop-win-x64.zip`, `openclaw-desktop-osx-arm64.zip`, and `openclaw-desktop-linux-x64.zip`. Each archive contains Companion, the NativeAOT gateway, and the NativeAOT CLI. The README's instructions are to extract the archive, launch Companion from the `companion` folder, and continue from there. The README text supplied here is truncated at that step, so the remainder of the desktop flow is not something I can describe.
The second path is a source checkout. The README points to `docs/QUICKSTART.md` as the supported local setup path and `docs/START_HERE.md` as the evaluator overview. It also states that CLI and Companion setup flows exist for source checkouts and desktop bundles, which suggests the CLI can drive initial configuration rather than requiring you to hand-edit files.
Configuration keys appear in the README in a few places. `Runtime.Orchestrator=maf` selects the Microsoft Agent Framework adapter, described as first-class and optional, requiring no special build. Durable workflow delegation goes through supported backends such as `maf-durable-http`. The `/loop` command sets up recurring prompts with TickerQ-backed session-scoped timer injection, and `/goal` provides session-scoped auto-continuation until work completes, blocks, or hits a budget limit. I cannot list the full config schema from this material, so treat the docs site as the source for anything beyond these keys.
Where the compatibility story gets thin
The README carries a badge reading "plugin compatibility: evolving". That is the project's own label, and it is the clearest limitation in the material. The claim of "practical reuse" of existing OpenClaw TS/JS plugins and `SKILL.md` packages sits next to a badge that says the compatibility surface is still moving. If your plan depends on a specific third-party plugin working unchanged, that is the thing to test first, not the thing to assume.
The identity question is the second issue. The README says AgentQi is "the broader developer-infrastructure direction behind OpenClaw.NET" and that "AgentQiX is the likely future runtime identity", while stating that OpenClaw.NET remains the current runtime and repository identity. A documented likelihood of a future rename is a migration cost you are accepting up front. It does not make the current release unusable, but it does mean pinning a version and reading release notes before upgrading.
Version cadence is visible from the releases: v0.1.3 in July 2026, v0.1.4 in August 2026, v0.2.0 in September 2026. A 0.x line with roughly monthly releases and a minor bump from 0.1 to 0.2 is a project still settling its interfaces. The "80+ native and optional tool surfaces" figure is the project's own count and is not broken down in the README, so you cannot tell from this material how many are native versus how many require an MCP app.
OpenClaw.NET against the Microsoft Agent Framework
The obvious comparison is the Microsoft Agent Framework, and OpenClaw.NET's relationship to it is not competitive. The README describes a first-class optional adapter selected with `Runtime.Orchestrator=maf`, plus durable workflow delegation through backends like `maf-durable-http`. So MAF is something this runtime can host, not something it replaces.
The more useful contrast is with a plain MAF application. If you write an agent directly against MAF, you own the HTTP surface, the channel integrations, the session store, the tool registry, and the diagnostics. OpenClaw.NET supplies those as a gateway with a chat UI, an admin UI, OpenAI-compatible endpoints, MCP support, websocket, health, and diagnostics already wired. The trade is control for surface area. You get channel adapters for a dozen messaging platforms and a provider list that includes Ollama and OpenAI-compatible endpoints out of the box, and in exchange you accept the project's abstractions for sessions, memory, and tool registration.
A second alternative is running a Python or TypeScript agent stack and calling it over HTTP. That keeps you on the larger ecosystem, but it puts a second runtime in your deployment and gives up the NativeAOT publishing path that the README treats as a headline property. The choice is essentially whether you want one language in production or the widest plugin pool.
Licence, maintenance, and what to check before adopting
The licence is MIT, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are included. That is a permissive licence with no copyleft obligation on your own code. It says nothing about the licensing of plugins or `SKILL.md` packages you load, and the README does not address that, so the licence of each third-party plugin is a separate question. This is a description of the licence text, not legal advice.
Maintenance cost is dominated by two things. First, the 0.x cadence: monthly releases with interface movement mean you should expect to read release notes before each upgrade, and the harness regression suite exists precisely so you can run `openclaw harness test` offline before trusting a runtime change. Second, the rename risk around AgentQiX. If that identity change lands, you will be tracking a project under a new name, and the README's own framing is that AgentQi remains the documentation home while OpenClaw.NET is the runtime you can use today.
What to verify first is concrete. Confirm that your target platform is covered by the desktop bundles or that the source checkout builds under NativeAOT for your workload, since AOT has trimming constraints that reflection-heavy code does not survive. Then confirm your required tools are native rather than MCP-bridged, and confirm the specific OpenClaw plugin you care about against the evolving compatibility badge. Those three checks map to the three claims in this README that carry the most risk.
Editorial conclusion
Adopt OpenClaw.NET if you are a .NET team that wants an agent runtime, gateway, and CLI in one repository and can build from source or run the published desktop bundles. Do not adopt it if you need a stable plugin contract, because the README labels plugin compatibility as evolving and names AgentQiX as a likely future runtime identity, which implies a rename or migration later. Verify the Quickstart path against your target platform and check whether the tools you need are native or only reachable through the MCP bridge before committing.
Community notes