Skip to content

win-hooks 1.14.0

Latest

Choose a tag to compare

@github-actions github-actions released this 31 Aug 17:03
· 2 commits to main since this release
v1.14.0
eec3ec7

Every hook runs through node now, and the generated wrapper scripts are gone

When win-hooks repaired a hook, it used to write a small bash script next to it and point the hook at that. It worked, but it meant every repair depended on finding a bash on the machine, and the repair itself was a piece of generated shell text that could only be checked by running it. A patched hook is now one line of JSON - what to run, and what to run it with - and node reads it. Bash is started only for the plugins whose hooks are genuinely shell scripts.

Two failures fall out of that change. The repair for a plugin script that calls an interpreter on itself was itself broken: it wrote a bash shebang followed by an exit, which is a syntax error to the very python or node that was invoking the file, so the hook kept failing with the message it had just been repaired for. Separately, a hook could not receive more than eight arguments, because the batch dispatcher forwarded them one position at a time. Both are gone. The generated scripts themselves are gone too, including the ones every earlier release left sitting in your plugins.

Hooks patched by an earlier version keep working and are migrated on the next run, so there is nothing to reinstall. One thing to know if you are on Codex: this release changes the hook manifest, so Codex stops dispatching win-hooks' own hooks until you trust them again, silently and with no error. npx @lilmgenius/win-hooks patch still repairs everything from outside the hook.

New

  • A patched hook is one JSON descriptor in hooks.map.json, read by a node dispatcher, instead of a generated bash script. A repair no longer needs bash unless the thing being repaired is a shell script.
  • The wrapper scripts an older win-hooks generated are deleted, so a hook directory holds only what something actually dispatches. Nothing was running them, but they are indistinguishable by eye from the bridge files that are still live, and a stale one is what a stale dispatcher used to reach for.

Fixed

  • The repair for a self-recursive hook script was broken, and left the hook failing with the same error it was repaired for. The neutral no-op is a lone #!/bin/sh line now, measured to exit 0 under python, node, and bash alike.
  • A hook could take no more than eight arguments. Nothing shifts positions any more, so the dispatcher forwards the whole command line.
  • A dispatcher left behind by an older win-hooks is now refreshed. It was only replaced while a plugin was being patched, so a plugin with nothing else wrong kept the copy that first repaired it - and an old copy looks for a wrapper script this release replaced, which made the hook exit silently while the health check still called it healthy. The dispatcher is now checked against the shipped one and refreshed before anything else is repaired.
  • The health report no longer runs its longest labels into the plugin name beside them. The column is measured from what is actually in the report.

Also

  • win-hooks is down to one language and one small exception. The bash bridge and the wrapper-script generator are gone; what is left is node, plus a single cmd/bash polyglot whose two halves do nothing but start node on it.
  • A bash.exe on PATH still has to prove it can see the script it is about to run, so WSL never accepts a hook and silently swallows it.
  • Coverage: 31 of 31 testable cases, one waived in writing.

Everything win-hooks repairs is listed in the README.

Install

# Claude Code
claude plugin marketplace add LilMGenius/win-hooks && claude plugin install win-hooks

# Codex
codex plugin marketplace add LilMGenius/win-hooks && codex plugin add win-hooks@win-hooks

# or a one-shot CLI fix
npx @lilmgenius/win-hooks