fix: use cross-platform wrapper for wt CLI in Claude Code integration

[lucaspimentel]

Summary

Currently, Worktrunk's Claude Code hook keeps opening Windows Terminal windows because it calls wt, which is an alias ~/AppData/Local/Microsoft/WindowsApps/wt.exe by default.

Windows users have three workarounds:

• install Worktrunk as git-wt.exe
• install Worktrunk as wt.exe and disable the Windows Terminal alias to avoid conflicts
• install Worktrunk as wt.exe and re-order the paths in PATH so Worktrunk is found first

Changes

• Add a wt.sh wrapper script that tries to find the correct Worktrunk binary.
• Update hooks.json to use wt.sh.
• Bump the plugin version.

Manual tests

Tested all scenarios (I hope)

• Windows (pwsh), Git Bash on Windows, WSL (Windows Subsystem for Linux)
• with Worktrunk installed as git-wt.exe or wt.exe
• with Windows Terminal wt alias enabled or disabled

[max-sixty]

thanks!

can we have it fall back to wt if git-wt doesn't exist? some people deactivate wt in windows

(unless there's some non-convoluted way to detect that wt is Windows Terminal — that would be ideal — @worktrunk-bot research any ideas!)

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9be3764104

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[worktrunk-bot]

A few options for detecting Windows Terminal's wt:

1. Path check — Windows Terminal lives at */WindowsApps/wt.exe. On MSYS/Cygwin, command -v wt or which wt would resolve to that path. If it contains WindowsApps, it's Windows Terminal.

2. Try git-wt first, fall back to wt — simplest approach that covers both cases (Windows with git-wt installed, and Windows where someone disabled the WT alias):

case "$(uname -o 2>/dev/null)" in
    Msys|Cygwin)
        if command -v git-wt.exe >/dev/null 2>&1; then
            WT=git-wt.exe
        else
            WT=wt
        fi
        ;;
    *) WT=wt ;;
esac

3. Hybrid — try git-wt first, fall back to wt only if it doesn't resolve to WindowsApps:

case "$(uname -o 2>/dev/null)" in
    Msys|Cygwin)
        if command -v git-wt.exe >/dev/null 2>&1; then
            WT=git-wt.exe
        elif command -v wt >/dev/null 2>&1 && ! command -v wt 2>/dev/null | grep -qi WindowsApps; then
            WT=wt
        else
            echo "worktrunk not found — install with: cargo install worktrunk --features git-wt" >&2
            exit 1
        fi
        ;;
    *) WT=wt ;;
esac

Option 2 seems like the right balance — simple, handles the "deactivated wt" case, and the worst that happens if someone only has Windows Terminal's wt is a confusing error (new terminal window opens) which is the same behavior they'd get without the wrapper. Option 3 adds detection but more complexity for an edge case.

@lucaspimentel what do you think — want to go with option 2 (fallback) or 3 (with WindowsApps detection)?

[lucaspimentel]

@worktrunk-bot can we combine both checks? "if (is windows) AND (git-wt.exe exists), then use git-wt.exe, else use wt"

[worktrunk-bot]

Done — pushed a commit that does exactly that: on Windows, tries git-wt.exe first via command -v, falls back to wt if it's not found. Non-Windows platforms still use wt as before.

[worktrunk-bot]

The WindowsApps detection on line 11 works, but the ${WT:=wt} default on line 16 undoes it: when git-wt.exe is absent and wt is Windows Terminal, neither branch sets WT, so the default still invokes Windows Terminal — the exact bug this PR fixes.

[worktrunk-bot]

The Windows Terminal detection logic looks good now. One bug: the final invocation line is duplicated, so every hook command will execute twice.

[max-sixty]

@lucaspimentel would you mind running this for a day or so to confirm it behaves well? It's difficult to test this stuff...

[lucaspimentel]

@max-sixty definitely. I opened the PR too quickly (edit: the fix wasn't as simple as I originally thought) 😅 I'll convert it to a draft while I keep testing. worktrunk-bot and I keep finding edge cases.

[max-sixty]

thank you v much @lucaspimentel !

[max-sixty]

@lucaspimentel to the extent you've been using this and it's been successful, we could consider merging...

[max-sixty]

@worktrunk-bot resopve conflicts

[worktrunk-bot]

Resolved and pushed (d3da440).

Conflict was in .claude-plugin/plugin.json — this branch added "version": "1.0.1", but main dropped the static version field entirely in #2402 (so Claude Code uses the commit SHA). Took main's side and removed the line.

Heads up — main also added WorktreeCreate and WorktreeRemove hooks in hooks.json that invoke bare wt, which auto-merged cleanly but undoes the wrapper coverage this PR introduces for the other three hooks. If you'd like them wrapped too, let me know and I can push that change.

[max-sixty]

@lucaspimentel give the go ahead if you've been using it and we should merge! ty!

[lucaspimentel]

@worktrunk-bot

Heads up — main also added WorktreeCreate and WorktreeRemove hooks in hooks.json that invoke bare wt, which auto-merged cleanly but undoes the wrapper coverage this PR introduces for the other three hooks. If you'd like them wrapped too, let me know and I can push that change.

Fix this.

[worktrunk-bot]

Done — pushed de3cd47b wrapping the WorktreeCreate and WorktreeRemove commands with wt.sh. All five hooks now go through the wrapper.

[lucaspimentel]

give the go ahead if you've been using it and we should merge

@max-sixty good to go, thanks!