Windows sandbox gives only Access denied for read-only WMI process-event subscriptions

Open 💬 0 comments Opened Jul 27, 2026 by Guffawaffle

Codex version

codex-cli 0.145.0

Environment

Windows Codex session using the default Windows sandbox.

What happened

While dogfooding a WPF launcher, both a packaged child process and a direct PowerShell probe attempted to subscribe to the read-only WMI process lifecycle events Win32_ProcessStartTrace / Win32_ProcessStopTrace. Starting the System.Management.ManagementEventWatcher failed with:

System.Management.ManagementException: Access denied

The failure exposed no sandbox-specific diagnostic or capability signal, so it initially looked like an application/runtime defect.

Expected behavior

One of the following would make this actionable without weakening sandbox safety:

  • permit this read-only subscription when it fits the Windows sandbox contract;
  • expose a capability/diagnostic that identifies WMI event subscriptions as sandbox-denied; or
  • document the restriction and recommended event-driven alternatives.

Workaround

The launcher replaced WMI with unprivileged RegisterShellHookWindow window-created events and a tracked System.Diagnostics.Process.Exited subscription. That works inside the same Codex session without interval polling.

Why this matters

Read-only lifecycle observation is useful for Windows desktop-app development. A bare Access denied loses the fact that the failure is environmental and can send application debugging down the wrong path.

View original on GitHub ↗