Windows: Codex Desktop never invokes trace-codex hooks — 0 traces delivered, "hook exited with code 1" for every lifecycle event

Examine the plugin's hooks.json file and the bin/codex-hook.sh script to understand the hook execution flow. Investigate how Codex Desktop on Windows loads and runs hooks, possibly by checking the MSIX package structure and logs in %LOCALAPPDATA%\Packages\OpenAI.Codex_\LocalCache\Local\Codex\Logs. Determine if the issue is in path resolution, sandboxing, or a missing hook dispatch mechanism. The goal is to get a hook to execute successfully and deliver a trace.

Summary

On Windows, trace-codex installs and shows as active in Codex Desktop (Settings > Plugins),
but every single hook (SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, etc.) fails
with "hook exited with code 1" in the Codex Desktop hooks panel, and zero traces are
ever delivered to Braintrust — confirmed via the dashboard (0 spans over a 1-hour window
with multiple test sessions).

Environment: bt CLI v0.19.3 (also reproduced after bt update), Windows 11, Codex Desktop
(OpenAI.Codex package), trace-codex plugin v2.0.0.

What we ruled out

The plugin's hooks.json runs commandWindows: bash "${PLUGIN_ROOT}\bin\codex-hook.sh",
trusting that bash on PATH is Git Bash. On our machine PATH resolves bash to the WSL
launcher stub (AppData\Local\Microsoft\WindowsApps\bash.exe) instead of Git Bash, which
corrupts any backslash-containing path/argument passed to it (confirmed: echo $HOME
through that stub returns C:Users<name>, every backslash stripped).

We patched hooks.json to call Git Bash by its absolute path instead of relying on PATH,
restarted Codex Desktop, and the hooks panel still showed hook exited with code 1 for
every entry — no change.

We then searched Codex Desktop's own logs
(%LOCALAPPDATA%\Packages\OpenAI.Codex_<id>\LocalCache\Local\Codex\Logs\...) for any
reference to codex-hook.sh, PLUGIN_ROOT, or the hook's statusMessage ("Braintrust
tracing") across every session logged that day — zero matches, before or after the
patch. This strongly suggests Codex Desktop never actually reads/executes the hooks.json
under ~/.codex/plugins/cache/braintrust-codex-plugins/trace-codex/2.0.0/hooks/hooks.json
at all for lifecycle hook dispatch on Windows.

We also checked whether Codex Desktop keeps its own isolated copy of the plugin config
(it runs as an MSIX-packaged app, Packages\OpenAI.Codex_<id>\...): LocalState and
RoamingState under that package are genuinely empty (no permission error, just empty),
there is no non-virtualized %LOCALAPPDATA%\Codex path outside the sandbox, and the only
Windows-specific executables present (codex-command-runner.exe,
codex-windows-sandbox-setup.exe) are compiled binaries we can't inspect. Codex Desktop's
logs do show it actively enumerating installed WSL distros
([wsl] eligible distro list ... Ubuntu Running), and Braintrust starts as an MCP server
in the same logs (server=braintrust status=ready) — a different mechanism from the
lifecycle-hook path the CLI uses.

Impact

Codex Desktop tracing is completely non-functional on Windows — not degraded, not
intermittent, zero spans delivered, with no error surfaced to the user beyond a generic
"hook exited with code 1" in a panel most users won't open.

Ask

Could someone confirm where Codex Desktop (as opposed to Codex CLI) actually reads its
hook/plugin configuration on Windows? If hooks.json's commandWindows field isn't the
real codepath for Desktop, what is, and is there a supported way to fix/patch it today —
or is this simply not implemented yet for Codex Desktop on Windows?

Related: braintrustdata/braintrust-claude-plugin#41 (same family of Windows execution
issues, different product/mechanism).