win-hooks 1.14.0

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

win-hooks 1.13.0

The run you could not see, and the one that never happened

win-hooks now says one line at the start of every session: which host it checked, how many hook files it looked at, how many it repaired, and what is still open. Until now a quiet session meant either a clean machine or a hook that never fired, and nothing you could read told you which one you had.

On Codex it was usually the second. Every hook win-hooks patched was failing at exit 1 with no output, because the Windows command it wrote was assumed to reach cmd.exe and was handed to PowerShell instead, which reads a leading quoted path as an expression and rejects the argument after it. Patched hooks now open with cmd /c, the one form Windows PowerShell 5.1, pwsh 7, and cmd.exe all execute, and the test materializes the real command and runs it through every edition installed on the machine.

One thing to know when you upgrade on Codex: Codex remembers a hash of each hook it trusts, and this release changes the hook manifest, so it stops dispatching win-hooks' own hooks until you trust them again. It does that silently, with no warning and no error. npx @lilmgenius/win-hooks patch still repairs everything from outside the hook, and win-hooks will never write that trust record on your behalf.

New

• A line at session start naming the host, the hook files checked, the repairs made, and the issues left open. Only at session start: nothing else writes where a model would read it on every prompt.

Fixed

• Every patched Codex hook ran and failed, leaving no output and no heartbeat. The Windows command now opens with cmd /c, and a hook patched before this release is re-derived on the next run. A commandWindows a plugin author wrote is still left alone.

Also

• The suite executes the real emitted command from a plugin folder whose name contains a space, under every PowerShell edition present, rather than stopping at the first shell that works. Coverage: 30 of 30 testable cases, one waived in writing.
• Nothing win-hooks ships can write Codex's hook-trust record, and a test holds it to that. A repair tool able to grant itself hook trust would be a supply-chain hole.

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

win-hooks 1.12.0

One command, and it decides for you

There is one thing to run when a plugin breaks on Windows: /win-hooks:patch. It looks first, tells you what it found, repairs whatever is not healthy, and shows you the result. A healthy machine is reported and left alone.

Before this you had to choose. /win-hooks:status checked, /win-hooks:fix repaired, and knowing which one you needed was your problem - though nobody inspects hooks for their own sake, and a broken one was always going to be repaired. The order that made the pair usable lived as steps in a prompt, so it held only as long as the model followed it. It is now one path through the engine.

New

• /win-hooks:patch replaces status and fix, and the separate diagnose skill folds into it. A skill is a superset of a command: it takes the same arguments when you type it, and it also recognizes the error on its own when you paste one in.
• The symptom table, the issue vocabulary, and the repair steps are written once instead of across four files.

Also

• The test suite is a single Node program. Fixture plugins are data rather than scripts in a second language, leaving one deliberate .cmd shim where Windows itself requires one. Coverage: 27 of 27 testable cases, one waived in writing.
• win-hooks describes itself the same way wherever you meet it - the marketplace, both plugin manifests, npm, and the top of the README all read Windows auto-patcher for vibe coders. Every one is a copy of a single line in package.json, and a release refuses to build if any of them has drifted.

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

win-hooks 1.11.0

Half a second, and a suite that proves it

win-hooks was a shell pipeline that read hook commands as text and took 21 seconds to repair both hosts. It is now a single Node engine that parses hooks.json as JSON and finishes in 0.45 seconds.

Reading text was not only slow, it was wrong in a way that kept coming back: four separate bugs were an awk or sed substitution mangling a quote or a path, and against a parsed object none of them can be written. The speed came from deleting roughly 300 process forks rather than from tuning - forking was the runtime.

Fixed

• A PATH bash that is really the WSL launcher swallowed every hook and reported success, so on a machine with WSL but no Git for Windows the repair looked fine and did nothing, forever. A candidate now has to prove it can read the script it is about to run.
• The SessionStart timeout was declared in milliseconds. The shipped 60000 meant 16.6 hours, so a hung run would have hung the session instead of being killed. Both hosts now declare it in seconds.

Also

• The per-prompt check stats a cached watch list instead of enumerating plugins, so it is free on the hot path.
• Coverage is derived from the documented case list rather than claimed: 26 of 26 testable cases, one waived in writing.
• Releases publish from the tag push, with an npm provenance attestation.

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

win-hooks 1.10.0

Plugins written for a Mac, working on your Windows machine

Every Claude Code and Codex plugin assumes a Unix machine. On Windows their hooks fire .sh scripts cmd.exe cannot run, call Unix tools that are not on the launch PATH, and carry invisible BOM or CRLF bytes that break a parser, so a session opens with a wall of red errors that is nobody's fault. win-hooks scans the plugins you have installed and repairs those hooks automatically, at every session start, keeping the original file backed up beside the patched one.

It also stays fixed: a plugin update that reverts its hooks is re-patched on the next prompt, and a prompt where nothing changed costs nothing.

New

• Both hosts, one engine. The Codex path writes Codex's native commandWindows field and leaves the portable command untouched, so a patched plugin keeps working on macOS and Linux - thanks to @jml226 (#1) for it.
• A standalone CLI. npx @lilmgenius/win-hooks runs the same repair without installing the plugin.
• /win-hooks:status and /win-hooks:fix report and repair on demand, and the diagnose skill maps an error message you paste in to its cause.

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