Codex activity hooks fail on Windows because bare bash resolves to WSL

[McNultyyy]

Summary

The Codex-native activity hooks added via #3364 can fail repeatedly on Windows because the plugin manifest invokes bare bash and provides no commandWindows override.

Affected lifecycle events can surface:

Hook failed
  └ hook exited with code 1

Reproduction

The active inline hooks in plugins/worktrunk/.codex-plugin/plugin.json use commands shaped like:

bash $PLUGIN_ROOT/hooks/wt.sh config state marker set 🤖 || true

On Windows, bare bash can resolve to the WSL launcher rather than Git Bash. In a sandboxed Codex session, that launcher fails to start with:

Access is denied.
Error code: Bash/Service/CreateInstance/E_ACCESSDENIED

Git Bash works when addressed explicitly. Because the hooks are trusted and enabled, the failure repeats across prompt, permission, stop, and session lifecycle events.

Expected

The Codex plugin hooks should work on Windows without depending on which bash.exe wins PATH resolution. Optional marker failures should not produce repeated hook-failure banners.

Codex supports a Windows-only commandWindows override for command hooks: https://learn.chatgpt.com/docs/hooks

A Windows handler could use PowerShell/direct git-wt.exe, or explicitly launch Git Bash. It should avoid bare wt.exe, since that name resolves to Windows Terminal on Windows, and preserve the current best-effort/non-blocking marker behavior.

Relationship to existing issues

#3362 identified accidental Claude-hook discovery in Codex, and #3364 introduced the current Codex-native inline hooks. This is a follow-up specific to Windows command execution; neither issue covers commandWindows, WSL Bash resolution, or this failure mode.

[worktrunk-bot]

Thanks for the report — the diagnosis holds up, and I've opened #4008 with a fix.

Confirming the mechanism against Codex's source rather than inferring it: hook commands run through the platform shell, which is cmd.exe /C on Windows (default_shell_command, codex-rs/hooks/src/engine/command_runner.rs), so the bare bash in each command is resolved by Windows PATH search and lands on System32\bash.exe — the WSL launcher — rather than Git Bash. And commandWindows does exactly what you describe: it replaces command on Windows (command_windows.unwrap_or(command) in codex-rs/hooks/src/engine/discovery.rs), so a per-handler override is the right lever.

The PR gives all four hooks a commandWindows that calls a new cmd.exe shim, hooks/wt.cmd. It mirrors what wt.sh already does on Windows — WORKTRUNK_BIN, else git-wt.exe, else a wt.exe PATH entry that isn't Windows Terminal's app alias — so bare wt.exe is never invoked, per your note. The tail is || exit /b 0, the cmd.exe spelling of the existing || true, which keeps a missing install from raising the banner at all.

How it was verified, and what wasn't

Two new tests. The first pins the manifest shape and was written before the fix — it failed on the shipped manifest, naming the exact hook command from your report. The second runs the real commandWindows the way Codex spawns it (${PLUGIN_ROOT} substituted textually, then cmd.exe /C "<command>" with the command line as one quoted raw argument) and asserts UserPromptSubmit stores 🤖, Stop swaps it for 💬, SessionEnd clears it, and that a hook which can't find worktrunk still exits 0. It runs on the Windows leg of CI, which went from 4329 to 4331 tests, all passing — so cmd.exe's quote handling, the shim's control flow, and the emoji argument surviving cmd.exe intact are checked on a real Windows runner.

What that doesn't cover: nothing here drives an actual Codex session on Windows, so the end-to-end claim rests on reading the two Codex source files above. If you're able to try the branch, confirmation that the banners stop would be useful.

Two adjacent surfaces are deliberately untouched, as separate concerns: the Gemini extension's hooks use the same bare bash (its Windows hook execution isn't established here), and Claude's hooks are unaffected because Claude Code runs them through Git Bash on Windows.

A maintainer will review the PR.