OpenClaw Windows Hub: A Native Gatekeeper for Agent Capabilities on Windows
Windows companion suite for OpenClaw - System Tray app, Shared library, Node, and PowerToys Command Palette extension.
At a glance
- What is it?
- OpenClaw Windows Hub is a C# companion suite that connects a Windows PC to an OpenClaw gateway, exposing selected capabilities to agents while layering sandboxing and permission checks. It is a practical tool for users who want control over what agents can do on their machine.
- Who is it for?
- Adopt OpenClaw Windows Hub if you run OpenClaw on Windows and want a graphical way to manage which agent capabilities are exposed, with per-feature toggles and a sandbox for command execution. Skip it if you have no gateway or prefer to manage everything through configuration files, since the app assumes a gateway exists and the README explicitly says you should not need to edit openclaw.json by hand.
- 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 last received commits 1 day ago.
- 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 14, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What This Companion Actually Solves
OpenClaw is an agent platform, but its Windows companion is not another agent runtime. It is a control plane and a capability broker. The problem it addresses is blunt: when an agent can run shell commands, drive a browser, or read your screen, someone has to decide which of those actions are acceptable on a given PC. OpenClaw Windows Hub gives that decision a native Windows interface and a set of default checks. It is for users who already run an OpenClaw gateway, either locally in WSL or remotely, and want to attach a Windows machine as a node. The README is explicit that the app can install a local gateway in WSL, but it does not replace the gateway. If you have no gateway and no intention of running one, this project is not your entry point.
Node Mode and the Capability Advertisment Model
The core mechanism is Node mode. When you enable it in the Permissions page, the PC registers itself as a node and advertises only the capabilities you have switched on. The README lists eight capabilities: System tools, Browser control, Camera, Canvas, Screen capture, Location, Text-to-speech, and Speech-to-text. Each one maps to a set of agent actions. The key design point is that advertising a capability is not the same as granting it. Gateway policy and local Windows checks can still block a command after the node has advertised it. So there are at least two layers of enforcement: what the node says it can do, and what the gateway and the OS allow. The README stresses that privacy-sensitive capabilities like camera capture and screen recording stay off unless you turn them on, and that the app never silently opts into privacy-sensitive gateway commands. That is a deliberate trust boundary, and it is the reason the project exists.
Getting It Running: Installer, Setup Wizard, and Configuration
Installation is a downloaded executable, one for x64 and one for ARM64. The README lists direct links to the latest release assets. No source build is required, which is a relief for a .NET project. On first launch, the setup wizard asks whether you want to install a local gateway in WSL or connect to an existing gateway. If you have no gateway, the README tells you to choose the WSL option. After that, the path is through the tray menu: Companion Settings, then Connection to pair with the gateway, then Sandbox to choose containment, then Permissions to enable Node mode and pick capabilities. The app saves changes automatically. The README says you should not need to edit openclaw.json by hand, which is a strong claim for a tool that also exposes an Advanced > Config section with a schema-guided editor. That editor exists for cases where the gateway is not managed by the app, so the claim is about the normal flow, not about all configurations.
Sandbox Execution: MXC Isolation and the Fallback Risk
The Sandbox page controls programs launched through the system.run capability. There are three presets: Locked Down, which blocks internet, clipboard, and standard user folders; Recommended, which allows internet, read-only access to common folders, and clipboard read access; and Unprotected, which allows broad access. You can also set custom controls for folder, network, clipboard, timeout, and output limits. The important technical detail is that the node uses MXC process isolation when it is available. MXC is a Windows mechanism, though the README does not explain what it stands for or how it works internally. If MXC is unavailable and strict fallback blocking is off, the node can fall back to uncontained host execution. That is a real failure mode. A user who assumes the sandbox is always active could be running commands without isolation. The README says the Sandbox page shows the current state, which is where you would notice the fallback, but it is a subtle risk for anyone who does not check that page regularly.
Gateway Allowlist: A Second Trust Check with Manual Steps
Beyond the local permissions, the gateway applies its own command allowlist. The README includes an example JSON shape for an externally managed gateway. It lists commands like system.notify, canvas.present, screen.snapshot, and device.info. Canonical paired Windows nodes receive desktop system.* defaults, including system.run, system.run.prepare, and system.which. But commands like screen.record, camera.snap, stt.transcribe, and tts.speak are not in the defaults. They require deliberate gateway opt-in. The README warns that wildcards such as canvas.* are not expanded, so you must list each command explicitly. After changing the gateway command policy, you must approve any pending-reapproval request shown by the app and reconnect the node. This is a manual, two-step process that is easy to forget. If you skip the reapproval, the node may advertise capabilities that the gateway will still block, or vice versa. The Command Center page exists to resolve these warnings, but the need for it shows that the trust model is not fully automatic.
Limitations and Wrong-Use Cases
The most obvious limitation is the Windows version requirement: 10 20H2 or later, or Windows 11. That excludes a large population of older but still functional Windows 10 machines. Another limitation is the dependence on WSL for the local gateway option. If you do not want WSL, you must have an existing gateway elsewhere. The sandbox fallback to uncontained execution is a genuine weakness, because it means the advertised security guarantee is conditional. Also, the README is thin on details about MXC. It does not say what MXC requires in terms of hardware or OS features, so you cannot verify from this material whether your machine will support it. This is the wrong tool if you want a purely headless or scriptable setup, because the entire workflow is driven by a graphical tray app and a setup wizard. The deep links like openclaw://settings exist for automation, but the primary path is interactive.
Alternatives and the Difference in Approach
The natural alternative is to run OpenClaw without this companion, managing the gateway and its commands through configuration files and the gateway's own tools. The README even acknowledges this by including an externally managed gateway allowlist shape. That approach puts everything in openclaw.json, with no tray app, no sandbox page, and no permission toggles. The difference is the enforcement point. With the companion, the Windows node itself enforces capability advertisement and local sandbox policy. Without it, you rely entirely on the gateway's allowlist and whatever local script or service you have written. The companion also adds a global hotkey, toast notifications, and a local MCP server, which a configuration-file setup does not provide. If you are comfortable editing JSON and do not need a GUI, the alternative is lighter. If you want per-capability switches and a visual indicator of node status, the companion is the intended path.
Maintenance, Updates, and License
The project is under the MIT license, which means you can reuse the code with few restrictions, but the README does not discuss contribution guidelines or governance. The app supports background updates from GitHub Releases, so maintenance is partly automated. The release cadence appears active, with a stable v2026.7.1 and an alpha v2026.7.2-alpha.19 in the same month, but the README does not describe a migration path between versions. The dependency on WebView2 for Canvas and A2UI rendering means you need the WebView2 runtime, which is common on modern Windows but not guaranteed. The local MCP server and the deep link IPC are features that could break with gateway protocol changes, and the README does not specify a compatibility policy. Before adopting this in a production environment, you should verify that the gateway version you run matches the companion's expected API, and check the docs site for any version matrix.
Editorial conclusion
Adopt OpenClaw Windows Hub if you run OpenClaw on Windows and want a graphical way to manage which agent capabilities are exposed, with per-feature toggles and a sandbox for command execution. Skip it if you have no gateway or prefer to manage everything through configuration files, since the app assumes a gateway exists and the README explicitly says you should not need to edit openclaw.json by hand. Before deploying, verify that your Windows version is 10 20H2 or later, confirm that MXC process isolation is available on your machine, and review the gateway allowlist to ensure commands like screen.record or camera.snap are deliberately opted in, as they are not enabled by default.
Community notes