Native Windows
The support boundary for native Windows x64 installs, connectors, enforcement, telemetry, and operations.
DefenseClaw has a native, per-user Windows x64 (amd64) distribution. It
installs a local gateway, native hook launcher, CLI, TUI, scanners, and managed
Python runtime. Connector availability, setup, paths, and platform-specific
quirks live on the connector pages, next
to the equivalent macOS/Linux guidance. A supported availability label does
not populate validation evidence or certify an official-client run.
For centrally managed endpoints, the separate
managed-enterprise lifecycle
installs four administrator-owned Windows services: DefenseClawGateway,
DefenseClawCMIDBroker, DefenseClawHookGuardian, and
DefenseClawHookEnumerator. It is explicitly opt-in and does not change this
per-user package or its existing auto-heal behavior.
WSL is not supported
This guide is for DefenseClaw, the agent, and its configuration running in the same native Windows user session. Do not install DefenseClaw in WSL, point a native agent at a WSL installation, or mix native and WSL connector homes.
Support language
| Status | Meaning in this guide |
|---|---|
| Supported | Implemented and available through ordinary native Windows x64 Setup. This availability label does not populate validation metadata or claim authentic client evidence. |
| Limited | Supported only on the stated surface, with optional configuration, an extra dependency, or a narrower guarantee. |
| Unsupported | Rejected, unavailable, or outside the native Windows product contract. |
| Not applicable | A platform-specific concept is intentionally absent from the Windows design. |
Choose a connector
The connector platform table is the canonical Windows support matrix. Each linked connector page contains both platform setup paths and calls out native Windows dependencies, unsupported topologies, reload behavior, and event-specific enforcement limits.
Supported native Windows connectors remain connected directly to their normal upstream service. DefenseClaw does not insert a model proxy on Windows. It can protect and observe only events the installed agent emits through a documented hook, awaited policy, or native telemetry surface.
Install and maintain
Requirements, authenticated release Setup, repair, upgrade qualification, recovery, and uninstall.
Choose a connector
Compare macOS/Linux and native Windows support, then open one connector's setup and quirks.
Managed enterprise
Gateway, credential broker, hook guardian, profile enumerator, non-admin guarantees, and the enterprise CLI lifecycle.
Capabilities
Connector enforcement, native ask, fail-closed, and subprocess capabilities.
CLI commands
Canonical command reference with platform-specific availability notes.
Windows security model
Loopback authentication, local audit, scoped credentials, release provenance, and recovery guarantees.
Paths and troubleshooting
Filesystem reference, safe diagnostics, terminal guidance, and verification checklists.
Native architecture
The normal installation is one current-user application:
DefenseClawSetup-x64.exeinstalls product-owned files and an embedded runtime below the current user's Programs directory.- Connector setup installs the exact native hook, adapter, or in-process policy bridge documented on that connector's Windows tab. Use the connector platform table as the canonical source for process, path, dependency, and enforcement details.
- The native hook, adapter, or in-process bridge sends declared events to an authenticated gateway API on loopback. Action mode can return a decision only where that agent event or awaited policy phase supports one.
- Native OTLP from the agent enters a connector-scoped loopback receiver. It adds telemetry; it is never an enforcement path.
- The gateway evaluates policy and persists mandatory local audit data. Any outbound observability destination is an additional, explicit choice.
See Telemetry and security for the authentication, redaction, and local-storage boundaries.
What is outside the support boundary
| Item | Status | Boundary |
|---|---|---|
| WSL installation or a mixed native/WSL connector | Unsupported | Native and WSL executables, profiles, and hook paths are different trust domains. |
| Windows x86 | Unsupported | Setup requires an amd64 process and payload. |
| Windows ARM64, including x64 emulation | Not certified | Setup rejects it rather than relying on emulation. |
| Machine-wide Setup or MSI | Unsupported | The public package accepts INSTALLSCOPE=user only. |
| Elevated, service, session-zero, or background Setup | Unsupported | State-changing Setup actions require the signed-in, non-elevated interactive user. |
| Windows model-proxy connectors | Unsupported | The native Windows gateway supports connector hook, plugin, and awaited-policy lanes, not the guardrail-proxy lifecycle. |
| A remote agent-to-DefenseClaw gateway topology | Not certified | The certified connector path is same-user native hooks to loopback. Remote observability destinations are separate. |
OpenShell sandbox and sandbox commands | Unsupported | The Windows release does not host the Linux sandbox lifecycle. |
systemd, launchd, Unix sockets, and DefenseClaw-provided POSIX hook shells | Not applicable | Windows uses native processes and Windows process identity. DefenseClaw uses the packaged hook executable, a managed adapter, or an in-process bridge and does not add WSL or a POSIX shell. A connector page calls out any separate upstream runtime dependency, such as Devin's own Windows hook runner. |
| Machine services from the public per-user Setup | Unsupported | The current-user Setup never elevates or installs services. The separate managed-enterprise lifecycle installs DefenseClawGateway, DefenseClawCMIDBroker, DefenseClawHookGuardian, and DefenseClawHookEnumerator. |
| Docker Desktop WSL2 backend for bundled local stacks | Not certified | The optional certified local-stack path uses Linux containers on the Hyper-V backend. |
No roadmap is implied by these classifications.
If you are migrating
For a normal-mode migration from macOS or Linux, expect a per-user Setup EXE instead of a shell installer,
HKCU PATH and Run registration instead of a service manager, native process
identity instead of PID-only signaling, and the selected connector's native
hook, adapter, plugin, or awaited-policy lane instead of a DefenseClaw POSIX
hook script. Sandbox and proxy connector features do not move with you.
From WSL, perform a fresh native install. Install the selected supported connector natively for the same Windows user, follow its Windows setup tab, and do not copy a WSL data directory, hook scripts, tokens, virtual environment, gateway binary, or connector configuration into the Windows profile.
Continue with Install and maintain, then use the post-install checklist.