Three platforms, one release rhythm — with honest gaps
Capability levels: FULL / LIMITED / UNAVAILABLE per platform capability, as verified by current research and engineering tests — not marketing tables.
| Capability | Windows | macOS | Linux |
|---|---|---|---|
| Agent-layer hooks (Claude Code, OpenClaw, MCP proxy) | FULL | FULL | FULL |
| Process & lineage observation | FULL (user-mode; ETW kernel session optional, admin) | FULL (libproc polling, zero-privilege; real-time events need Apple EndpointSecurity entitlement — approval-gated, pending) | FULL (procfs, zero-privilege) |
| File action visibility | FULL user-mode; kernel-level pre-action PLANNED | LIMITED (polling cadence; real-time via entitlement, pending) | FULL visibility; enforcement via eBPF PLANNED (Phase 2) |
| Network observation | FULL with admin ETW session; LIMITED user-mode | LIMITED (polling) | FULL/LIMITED (procfs + auditd for kernel events) |
| Native enforcement (blocking) | PLANNED per phase | PLANNED | PLANNED (eBPF) |
| Recovery / undo | PLANNED (snapshot backends per OS) | PLANNED | PLANNED (btrfs + eBPF, Phase 2) |
What that means in practice
- Windows: unsigned binaries + SmartScreen guidance at first release (no paid signing in Early Access); full user-mode observation without admin, richer with an ETW session
- macOS: ad-hoc signed, right-click-to-open guidance; zero-privilege polling now, real-time events when the EndpointSecurity entitlement path completes
- Linux: single static binary, procfs-based monitoring; kernel enforcement is a deliberate Phase-2 step
- HarmonyOS: planned, implemented per official open capabilities
Every OS update runs compatibility contract tests (API, enforcement, performance, recovery) — an OS update must never force a core rewrite.