Fix Windows Cursor hooks + Scoop app-dir naming (#1424)

main

Commit

Karthik Rameshkumar2mo ago

Three independent Windows breakages reported in #1424:

  1. Scoop installed the CLI under the app dir cli (…\scoop\apps\cli) because goreleaser defaults the scoop manifest name to the project name, which resolves to the repo name. Set scoops[].name: entire so it installs as entire.

  2. entire configure --absolute-git-hook-path failed with "failed to resolve symlinks … The system cannot find the path specified" because filepath.EvalSymlinks can't resolve Scoop's current\ NTFS directory junction. Fall back to the unresolved os.Executable() path on Windows (extracted into resolveHookExePath for cross-platform testing) — that path is valid and, on Scoop, more stable across updates.

  3. Cursor agent hooks never fired on Windows: InstallHooks hardcoded the POSIX sh -c '…' wrapper, which silently fails to launch when Cursor spawns the command via the native shell with no runnable POSIX sh, and the silent wrapper hides the failure. Switch Cursor to the shared UseWindowsProductionHooks + WrapProductionSilentHookCommandForOS path (already used by codex) so it installs the native cmd.exe wrapper when no sh is present. Probe-gated: a no-op on non-Windows and on Windows hosts where sh works.

Other sh-based agents (gemini, claude-code, factory-droid) still hardcode the sh wrapper; copilot-cli deliberately stays sh-based because it runs hook commands via a bash field, not the native shell. Auditing/migrating those is left to a follow-up.

Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com Entire-Checkpoint: 01KXDH15JYQ4F8VJWSMH0YKA5J

Checkpoints

Fix Windows Hooks and Cursor Installation Issues

Claude CodeOpus 4.8[1m]
View session
Checkpoint 1