[worktrunk-bot]

Problem

Codex resolves a hook command through the platform shell — /bin/sh -lc on Unix, cmd.exe /C on Windows (default_shell_command). All four Codex hooks in the plugin manifest lead with a bare bash, and under cmd.exe that resolves through the Windows PATH to System32\bash.exe — the WSL launcher, not Git Bash. In a sandboxed session the launcher refuses to start (Access is denied. Error code: Bash/Service/CreateInstance/E_ACCESSDENIED), so every prompt, permission request, turn end, and session end raises a Hook failed banner (#4007).

Solution

Git for Windows stays a requirement; only the bare name bash is the problem, since cmd.exe resolves it through PATH. Each hook now also carries Codex's per-handler commandWindows, which replaces command on Windows (command_windows.unwrap_or(command) in codex-rs/hooks/src/engine/discovery.rs). It calls a new cmd.exe shim, plugins/worktrunk/hooks/wt.cmd, that locates bash.exe by path the way find_git_bash does in src/shell_exec.rs — derived from git.exe's install directory, then the system-wide and per-user install defaults — and then runs the same hooks/wt.sh that Claude, Gemini, and Unix Codex already go through. Worktrunk's own binary resolution stays in that one script instead of being spelled a second time in cmd.

Two details the shim inherits from the Rust resolver: Git\bin\bash.exe before Git\usr\bin\bash.exe, because the former is the wrapper that sets up the MSYS environment for a caller outside Git Bash (which is what puts uname within reach of wt.sh); and a PATH-scoped lookup, because an unscoped where searches the current directory first — for a hook that's the user's project, so a git.exe committed to a repo would otherwise choose the bash every event runs. The lookup is spelled "%SystemRoot%\System32\where.exe" "$PATH:git.exe" on both counts: the $PATH: prefix scopes what is searched, and the absolute path to where.exe closes the same surface one level up — where is System32\where.exe rather than a cmd built-in, so cmd resolves that bare name from the current directory too.

wt.sh now clears WT before its branches. On Windows all of them can be skipped (neither git-wt.exe nor wt on PATH), and a hook is handed the caller's whole environment, so an inherited WT was what the final command -v "$WT" check accepted and ran.

The Windows commands brace the plugin root as ${PLUGIN_ROOT} because Codex substitutes only that form textually, before the shell runs; the unbraced $PLUGIN_ROOT the Unix commands use survives to /bin/sh, and cmd.exe would pass it through literally. The tail is || exit /b 0, the cmd.exe spelling of the Unix || true: a marker is decoration, and a nonzero exit is what raises the banner. .gitattributes pins plugins/worktrunk/hooks/*.cmd to a CRLF checkout, since cmd.exe resolves a goto label by seeking through the file and can fail that search on an LF-only batch file.

Two doc changes ride along. plugins/worktrunk/CLAUDE.md records why every hook carries commandWindows, the shim's resolution order and the two lookup-scoping decisions, and why SessionEnd keeps timeout: 3 (Codex's ceiling for that event, so the longer Windows chain has no more budget to ask for). And because the CHANGELOG entry opens an ## Unreleased section, .claude/skills/release/SKILL.md step 9 now says to rename that heading at release time rather than insert a new one above it — otherwise the release ships a stale ## Unreleased.

Testing

Six tests, all new:

• test_codex_hooks_carry_windows_commands (all platforms) — pins that every Codex command hook has a commandWindows, that it names neither bash nor bare wt, that it calls the shim, and that the two PLUGIN_ROOT spellings stay on their respective sides. Written first: it failed on the manifest as shipped, with the exact hook command from the report.
• test_codex_windows_hook_commands_set_the_marker (Windows leg of CI) — runs the real commandWindows the way Codex spawns it, reproducing both steps: the ${PLUGIN_ROOT} substitution and cmd.exe /C "<command>" with the command line as a single quoted raw argument. It asserts UserPromptSubmit stores 🤖, Stop replaces it with 💬, SessionEnd clears it, and that a hook which cannot find worktrunk still exits 0. PATH is pinned to the shape a default Git for Windows install produces — Git\cmd and nothing else from the install — so the run covers cmd.exe's quote handling, the shim's search for bash, wt.sh running under the bash it picks, and the emoji surviving both hops.
• test_wt_sh_ignores_an_inherited_wt (Windows leg) — points WT at a real worktrunk, spelled the way bash can run it, on a PATH where wt.sh finds none itself, and pins that the inherited value is not what runs.
• test_shim_ignores_a_git_in_the_current_directory (Windows leg) — plants an unrunnable git.exe in the hook's current directory plus the bash.exe the shim would derive from it, puts a real Git and worktrunk on the pinned PATH, and asserts the shim prints a version line — which it could not do had it taken the decoy.
• test_shim_ignores_a_where_in_the_current_directory (Windows leg) — the same question one level up: a where.bat in the hook's current directory names a decoy Git install whose bin\bash.exe exists, so an unscoped where would reach the derive branch and leave BASH set and unrunnable rather than falling through to a real install. A separate probe pins the premise — that the planted where really does shadow System32\where.exe — so the test cannot go green because the decoy was never consulted.
• test_shim_derives_bash_from_the_git_on_path (Windows leg) — points ProgramFiles and LOCALAPPDATA at an empty directory, which leaves the derive branch as the only route to a bash. The two tests above go red only when the shim picks the wrong bash; this one goes red when the lookup finds nothing, so it is what observes that "%SystemRoot%\System32\where.exe" "$PATH:git.exe" survives the quoting for /f wraps it in.

What this does not verify

Nothing here drives a real Codex session on Windows, so the end-to-end claim — that Codex selects commandWindows and that the banner stops — rests on reading codex-rs/hooks/src/engine/{discovery,command_runner}.rs rather than on observation. What CI does exercise is the command string itself, executed the way that source says Codex executes it.

The shim's two standard-install fallbacks (%ProgramFiles%\Git, %LOCALAPPDATA%\Programs\Git) are unexercised by CI. Every test that reaches a bash takes the derive branch above them, and the one test that touches the fallbacks empties them to force that branch rather than to exercise them; they share the whole tail with it.

Two adjacent things are deliberately left alone, as separate concerns: the Gemini hooks at the repo-root hooks/hooks.json use the same bare bash (Gemini's Windows hook execution isn't established here), and Claude's hooks/hooks.json is unaffected because Claude Code runs hook commands through Git Bash on Windows.

---

Closes #4007 — automated triage

[worktrunk-bot]

Verified the mechanism against the upstream sources the PR cites, since the whole change rests on them: HookHandlerConfig::Command in codex-rs/config/src/hook_config.rs carries #[serde(default, rename = "commandWindows", alias = "command_windows")], discovery.rs does command_windows.unwrap_or(command) under cfg!(windows), its substitution fold is command.replace(&format!("${{{key}}}"), value) — braced form only — and command_runner.rs spawns cmd.exe /C with raw_arg(format!(r#""{command_line}""#)). All four claims hold, and the enum has no deny_unknown_fields, so an older Codex ignores the new key rather than failing the manifest. test (windows) is green on this head, which is what exercises the cmd.exe quoting, the goto resolution, and the || exit /b 0 tail.

One finding, inline: the shim doesn't clear its own locals, so an inherited WT bypasses the PATH scan it exists to perform.

[worktrunk-bot]

The inherited-WT finding from the last pass is addressed in c9a1721, and test_shim_ignores_an_inherited_wt is a real regression test for it — it fails on the pre-fix shim, and it stays honest about the runner's own PATH by pinning "the sentinel did not run" rather than "worktrunk ran".

Two things from this pass, both inline. The one worth a look before merge is the shim's binary resolution: where and cmd's bare-name lookup both reach the current directory, which is the repo the hook is running in — that is new surface relative to wt.sh, whose command -v is PATH-only. It is my own judgement that this wants a human rather than a repo rule; the deletion-surface hold in the review guidance doesn't cover it, since nothing here can delete anything. The other is the changelog entry.

Self-authored, so no approval either way. test (linux|macos|windows) and code-coverage were still in flight at this head; nothing had gone red.

[worktrunk-bot]

test (windows) was red at fd89ee1b on this PR's own new test, and 9e7458d3 fixes it correctly — starts_with("wt ") is the pin test_mock_dispatch_ignores_degenerate_argv0 in tests/integration_tests/init.rs already uses for the same question. Recording why it failed, since the old assertion could never have passed here: version_str() in src/cli/mod.rs resolves option_env!("VERGEN_GIT_DESCRIBE") first and falls back to CARGO_PKG_VERSION only when the build script couldn't set it — the crates.io-package case, not CI.

That failed run is also the evidence the $PATH: prefix was still missing. The shim exited 0 and printed wt ad1a14b, so where "$PATH:git-wt.exe" resolved to the copy on the pinned PATH and not to the invalid git-wt.exe decoy in the cwd — had it taken the decoy, cmd could not have run it at all. The syntax no longer rests on the where documentation; it ran, and 4332 of 4333 tests passed on that leg with nothing else red.

One finding on this pass, inline: eight lines in the new test that restate a guarantee std::process::Command already gives.

Self-authored, so no approval either way. CI at 9e7458d3 is still in flight.

[max-sixty]

but don't we already require git bash? and so avoiding using bash seems unnecessary?

(I thought I asked this before so apologies if this was answered somewhere else)

[worktrunk-bot]

We do require Git for Windows, and this PR doesn't relax that — wt's own hook and alias bodies still run through Git Bash. What breaks on Windows isn't whether bash exists; it's whether the bare name bash resolves to it. Codex spawns hook commands through cmd.exe /C, so bash is a Windows PATH lookup: Git for Windows' default install puts Git\cmd on PATH (which holds git.exe, not bash.exe), while WSL puts C:\Windows\System32\bash.exe there — so on a machine with WSL, the name lands on the WSL launcher with Git Bash installed and working, which is exactly what @McNultyyy hit in #4007.

We already treat those as two different claims elsewhere in the codebase: find_git_bash deliberately does not use which bash, deriving bash.exe from git.exe's install directory instead, with the same WSL reason in its doc comment. That was a real bug in wt's own hook execution once (b48b0ba); the Codex manifest is the one place still spelling bash as a bare name for a shell that resolves it by PATH. Claude's hooks are fine as they are because Claude Code runs hook commands through Git Bash itself rather than cmd.exe.

The bash-preserving alternative is real, and I'm happy to switch if you prefer its shape: commandWindows locates Git Bash and hands off to wt.sh as today. It costs about the same, just placed differently — details below.

Why the shim rather than locating Git Bash

To keep wt.sh, the Windows command has to find Git Bash by path, which means a cmd script doing roughly the three-candidate search find_git_bash does in Rust: derive ..\bin\bash.exe / ..\usr\bin\bash.exe from where git.exe, then %ProgramFiles%\Git\bin, then %LOCALAPPDATA%\Programs\Git\bin for a per-user install (#1259 was that last one). So it's a cmd shim either way — the choice is what the shim resolves, not whether there is one.

Given that, resolving the wt binary directly is the shorter path: each hook body is a single wt config state marker set … call with no shell syntax in it, so the bash hop buys nothing but a process launch, MSYS path translation on ${PLUGIN_ROOT}, and a Git Bash dependency for the marker hooks specifically. wt.cmd mirrors what wt.sh already decides on Windows (WORKTRUNK_BIN, else git-wt.exe, else a wt.exe that isn't Windows Terminal's alias), and the where "$PATH:…" prefix keeps the lookup off the hook's current directory.

The trade against it: wt.sh's Windows branch and wt.cmd now encode the same resolution order in two languages, and they can drift. If you'd rather have the single resolver, the Git-Bash-locating variant is the version to take, and the four tests on this PR port over to it with only the command string changing.

On "I thought I asked this before" — I don't find it on this PR or #4007, and no other thread I can see covers it, so nothing was dropped; it just hadn't been asked yet.

All checks are green at 86d3115, including test (windows) and codecov/patch.

[max-sixty]

The bash-preserving alternative is real, and I'm happy to switch if you prefer its shape: commandWindows locates Git Bash and hands off to wt.sh as today. It costs about the same, just placed differently — details below.

this seems reasonable, arguably simpler, but up to you if you've thought about it a lot

[worktrunk-bot]

The switch to the bash-preserving shape reads well, and the shim tracks find_git_bash faithfully: same derive-from-git.exe primary, same Git\bin before Git\usr\bin, same two install fallbacks — with %ProgramFiles% where the Rust version hardcodes C:\Program Files, which is the better of the two.

One finding, inline: where is itself still spelled as a bare name, so cmd resolves it from the hook's current directory — the same surface the $PATH: prefix closes one level down, and the mechanism is the one this file's own comment states.

Two things I could not settle from here, both bearing on that line rather than arguing against it:

• Neither Windows test would go red if the where lookup broke. The runner's Git is at C:\Program Files\Git, so a lookup that returns nothing falls straight through to the %ProgramFiles%\Git\bin\bash.exe fallback, which resolves — and test_codex_windows_hook_commands_set_the_marker and test_shim_ignores_a_git_in_the_current_directory both still pass. That is true of the line as it stands too: the evidence that $PATH: works is the earlier red run at fd89ee1b, not the suite. So whichever way the line ends up, the derive branch is unpinned, and a test that plants a bash.exe somewhere the fallbacks can't reach would be what makes it observable.
• SessionEnd keeps "timeout": 3, and the chain under it on Windows is now cmd.exe → for /f's child cmd → where.exe → bash.exe → wt.exe, against Unix's /bin/sh → bash → wt. I have no measurement of that on a cold Windows box, and I could not establish from here what Codex does when a hook times out — if it is the "Hook failed" banner, that budget is worth a look.

Self-authored, so no approval either way. At 4041caa, gate, fast-checks, feature-check, pre-commit.ci and codecov/patch are green; test (linux) and the advisory legs are still running.

[worktrunk-bot]

Switched to it — pushed as 4041caa.

wt.cmd now resolves bash.exe by path (the same order as find_git_bash: derived from where git.exe, then %ProgramFiles%\Git, then the per-user install) and then runs wt.sh, so the worktrunk-binary resolution lives only in that one script and Windows-Codex enters through the same door as Claude, Gemini, and Unix-Codex. The manifest commands didn't change. Net effect on the diff is smaller: the shim lost the WORKTRUNK_BIN → git-wt.exe → not-Windows-Terminal ladder and gained the bash lookup.

One thing the switch turned up: wt.sh never cleared WT, and on Windows every branch that assigns it can be skipped (neither git-wt.exe nor wt on PATH), so an inherited WT was what the final command -v "$WT" check accepted and ran. One line, and it now benefits all four integrations rather than just the cmd path — which is the argument for this shape, more or less.

All checks are green at 4041caa, including test (windows) and codecov/patch. One open review finding on the new commit (bare where resolves from the hook's cwd, the same surface the $PATH: prefix closes one level down) — that's being picked up separately, not folded in here.

What the Windows leg actually confirmed

The marker test pins PATH to the shape a default Git for Windows install produces — Git\cmd and nothing else from the install — rather than the runner's ambient PATH, so passing it settles two things I was inferring:

• Git\bin\bash.exe really is the wrapper that sets up the MSYS environment for a caller outside Git Bash. wt.sh branches on uname -o, and uname lives in Git\usr\bin, which a default install does not put on the Windows PATH. Had the wrapper not fixed that up, wt.sh would have fallen to its non-Windows branch, reached for bare wt, and the marker would never have been set. That is why the shim keeps find_git_bash's Git\bin before Git\usr\bin order — the raw usr\bin\bash.exe would not have done.
• The emoji survives the extra hop. It now crosses cmd.exe → Git Bash → wt instead of cmd.exe → wt, and MSYS converts the command line through its own charset, so this was the failure mode I most expected from the bash-preserving shape. test_codex_windows_hook_commands_set_the_marker asserts the stored marker contains('🤖'), not merely that the hook exited 0, so mojibake would have been red.

Still unverified, unchanged from before: nothing here drives a real Codex session on Windows, so "Codex picks commandWindows and the banner stops" rests on reading codex-rs/hooks/src/engine/{discovery,command_runner}.rs. CI exercises the command string executed the way that source says Codex executes it.

[worktrunk-bot]

Both findings from the last pass are closed, and the way the second one closed also settles what I said I could not check from here.

test_shim_derives_bash_from_the_git_on_path points ProgramFiles and LOCALAPPDATA at an empty directory, leaving :derive as the only route to a bash — the test I named as missing last pass ("a test that plants a bash.exe somewhere the fallbacks can't reach would be what makes it observable"). It also answers the quoting question I could only reason about: test (windows) is green at 2405b8b, so '"%SystemRoot%\System32\where.exe" "$PATH:git.exe" 2^>nul' does survive the cmd /c "…" wrapping for /f applies. Had it not, the shim would have reached :missing and exited 1 with both fallbacks emptied.

One finding, and it is the PR description rather than the code: it predates the last two commits. Testing still opens "Four tests, all new" and lists four; there are six, and the two it omits are this increment's substance — test_shim_ignores_a_where_in_the_current_directory and test_shim_derives_bash_from_the_git_on_path. Solution likewise still describes the lookup as where "$PATH:git.exe" rather than the %SystemRoot%\System32\where.exe it is now. The "what this does not verify" block does not need touching: the two install-default fallbacks genuinely remain unexercised, since the new test empties them rather than reaching them.

Nothing else this pass — no code findings. One thing worth naming for whoever merges, since it is not a defect: this diff edits plugins/worktrunk/hooks/wt.sh, which the review guidance lists as shipped automation and which the Claude WorktreeRemove hook runs wt remove --foreground "$p" through. The WT="" line changes which binary that resolves to, strictly narrowing it — an inherited WT could previously be executed with those arguments, and now cannot.

Self-authored, so no approval either way. At 2405b8b every check is green except test (linux), still running.

Upstream claims the new CLAUDE.md prose asserts, re-checked

The added paragraph makes three claims about code outside this repo that a reader can't cheaply confirm. All hold:

• SessionEnd's timeout ceiling. SESSION_END_DEFAULT_TIMEOUT_SEC = 1 and SESSION_END_MAX_TIMEOUT_SEC = 3 in codex-rs/hooks/src/events/session_end.rs; normalize_command_hook in codex-rs/hooks/src/engine/discovery.rs pushes "clamping {} hook timeout to {max_timeout_sec}s in {}" for anything larger, then .clamp(1, max_timeout_sec). So "omitting the key takes the 1s default, and a larger value is clamped with a warning" is exact, and timeout: 3 really is the whole budget the longer Windows chain can be given.
• The env vars test_shim_derives_bash_from_the_git_on_path relies on reaching a real hook. WINDOWS_CORE_ENV_VARS in codex-rs/protocol/src/shell_environment.rs lists SYSTEMROOT, PROGRAMFILES and LOCALAPPDATA. Worth adding to the test's own note: the inherit = "core" filter is followed by a default exclude of *KEY* / *SECRET* / *TOKEN*, case-insensitive — none of the three match, so the premise survives that step too.
• commandWindows replacing command, verified on an earlier pass and unchanged.

Separately, the .gitattributes CRLF pin is load-bearing rather than decorative: codex plugin marketplace add max-sixty/worktrunk reaches clone_git_source in codex-rs/core-plugins/src/marketplace_add/install.rs, which shells out to git clone (and git sparse-checkout / git checkout on the sparse path). That is a checkout, so plugins/worktrunk/hooks/*.cmd text eol=crlf applies on the user's disk and the goto labels resolve.