You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Hooks never execute on Windows — ${PLUGIN_ROOT:-...} is bash-only, no commandWindows variant #238
All three hooks in hooks/codex-hooks.json use ${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}. Codex spawns hooks via %COMSPEC%, which is cmd.exe. cmd.exe has no ${VAR:-default} expansion, so the token is passed through literally:
python3: can't open file '...\${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}\hooks\databricks-context.py': [Errno 22] Invalid argument
python: can't open file '...\${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}\hooks\databricks-context.py': [Errno 22] Invalid argument
Both fallbacks fail, so the hooks have never run on Windows. The scripts themselves are fine — invoked directly they exit 0 and emit correct JSON.
The failure is silent. The trailing || true masks it whenever Git for Windows' true.exe is on PATH (it ships at C:\Program Files\Git\usr\bin\true.exe). Under a narrower PATH the mask fails and codex reports SessionStart hook (failed) error: hook exited with code 1. So the observable symptom is environment-dependent, but the hook is non-functional either way.
Suggested fix: add a commandWindows variant using an absolute %PLUGIN_ROOT% path and a cmd-safe fallback (|| exit /b 0 rather than || true). Related upstream: openai/codex#34690.
I’m also experiencing this with plugin version 0.2.32.
In my tests, the hooks fail repeatedly in native Windows, both in Codex CLI and the Codex VS Code extension. Running those workflows inside WSL Ubuntu does not produce the hook failures.
The installed hook definitions still contain Bash-specific parameter expansion.
Separately, python and python3 in my native Windows environment currently resolve to Microsoft Store aliases, which may contribute to the execution failures.
Sharing this additional reproduction in case it helps investigate Windows compatibility.
Activity
ASCCJR commentedon Oct 20, 2026
I’m also experiencing this with plugin version 0.2.32.
In my tests, the hooks fail repeatedly in native Windows, both in Codex CLI and the Codex VS Code extension. Running those workflows inside WSL Ubuntu does not produce the hook failures.
The installed hook definitions still contain Bash-specific parameter expansion.
Separately, python and python3 in my native Windows environment currently resolve to Microsoft Store aliases, which may contribute to the execution failures.
Sharing this additional reproduction in case it helps investigate Windows compatibility.