Codex CLI on Windows/WSL triggers EDR alert due to PowerShell EncodedCommand toast notifications

Codex Codex CLI
1

Hi folks, has anyone else seen Codex CLI (running under WSL) trigger EDR alerts on Windows because of how desktop notifications are implemented?

What I observed

  • Running codex locally (Windows + WSL) triggered a security alert in our endpoint protection (FieldEffect).

  • The process tree looked like: wsl.exe → powershell.exe -NoProfile -NoLogo -EncodedCommand ...

  • When I decoded the command (from the alert), it was building a Windows Toast via Windows.UI.Notifications.ToastNotificationManager and base64-decoding the toast title/body (e.g., “Codex”).

So the payload itself appears benign (a toast), but the mechanism (PowerShell + -EncodedCommand launched from WSL) is extremely “malware-shaped,” so it makes sense it got flagged.

Why I’m posting
In a managed environment, I’d like to avoid repeatedly tripping SOC/EDR rules while still using Codex locally. I’ve already set:

[tui]
notifications = false

…but I’m not sure whether there are other notification paths (e.g., a notify = [...] hook, project-level .codex/config.toml, etc.) that could still spawn Windows-side notifications.

Questions

  1. Is the WSL → PowerShell -EncodedCommand toast path the expected implementation for Codex notifications on Windows/WSL, or is this a bug/regression?

  2. Besides tui.notifications = false, is there an official way to fully disable all OS-level notifications/hooks from Codex?

  3. For locked-down org environments: any recommended “safe mode” settings (e.g., ensuring no notify hook executes), or guidance for running Codex without triggering endpoint detections?

Happy to provide more sanitized details (versions, exact decoded toast builder snippet) if helpful. Mainly trying to confirm: is this known/expected, and what’s the best practice to prevent it?