Fix Git hooks that never run

Does this match your situation?

• git commit succeeds instantly and no lint, test or format step runs.
• 'hook was ignored because it's not set as executable'
• Hooks work for you but not for a teammate who just cloned the repository.
• Husky worked yesterday and stopped after you reinstalled node_modules.

Step-by-step fix

1. Find out where Git is actually looking

   Git runs hooks from exactly one directory, and core.hooksPath overrides the default .git/hooks. A value set globally — often left behind by an old tool — applies to every repository on the machine, and is the single most common reason Husky appears installed but does nothing.

   step 1Copy

   git config core.hooksPath
   git config --global core.hooksPath
   git config --show-origin --get core.hooksPath
   

   💡Empty output means Git is using .git/hooks. If the global value points somewhere unexpected: git config --global --unset core.hooksPath

2. Check the filename — Git matches it exactly

   Git looks for a file called pre-commit. Not pre-commit.sh, not precommit, and not pre-commit.sample. The .sample files Git ships with are deliberately inert; renaming one is how you switch it on.

   step 2Copy

   ls -l .git/hooks/
   mv .git/hooks/pre-commit.sample .git/hooks/pre-commit
   

3. Make it executable — and record that in the repository

   Git skips a hook without the executable bit and, since 2.36, prints a hint saying so. chmod fixes it on your machine; git update-index --chmod=+x stores the bit in the repository so every clone and every new branch inherits it. That second command is what stops the fix regressing for your team.

   step 3Copy

   chmod +x .husky/pre-commit
   git update-index --chmod=+x .husky/pre-commit
   git commit -m "chore: mark pre-commit hook executable"
   

   Show the Windows / PowerShell version

   Windows / PowerShellCopy

   # chmod does not exist on Windows — set the bit in Git's index directly
   git update-index --chmod=+x .husky/pre-commit
   

4. Check the shebang and the line endings

   Exit code 127 means 'command not found' — usually a missing shebang, CRLF line endings on a shell script, or a tool that only exists inside node_modules being invoked without npx. A hook that dies this way looks identical to one that never ran.

   step 4Copy

   head -1 .husky/pre-commit            # expect #!/usr/bin/env sh
   file .husky/pre-commit               # 'CRLF line terminators' is a bug here
   sed -i 's/\r$//' .husky/pre-commit   # strip CRLF
   

   ⚠️Add .husky/** text eol=lf to .gitattributes so Windows checkouts stop breaking the shebang line.

5. Reinstall the hook manager

   Husky writes its hooks during npm install via the prepare script. If someone cloned the repository and installed with scripts disabled, or .husky was gitignored, nothing was ever written.

   step 5Copy

   npm pkg set scripts.prepare="husky"
   npm run prepare
   
   # pre-commit (Python):
   pre-commit install
   

6. Confirm it fires — and know the escape hatch

   Commit something trivial and watch for output. Once it works, remember --no-verify exists for the genuine emergency rather than as a habit: it skips pre-commit and commit-msg entirely.

   step 6Copy

   git commit --allow-empty -m "test: hook check"
   git commit --no-verify -m "emergency: skip hooks"
   

Why this works

Hooks are ordinary executables Git runs by path at fixed moments. Git makes no attempt to interpret them, report on them, or tell you they exist — if the file is missing, misnamed, non-executable or in a directory Git is not reading, it simply carries on. That silence is deliberate, because hooks are never transmitted by clone or fetch: .git/hooks sits outside the object database, so a repository can never ship code that runs automatically on someone else's machine. Everything Husky, lint-staged and pre-commit do is a workaround for that one security decision — they keep hooks in a tracked folder and point core.hooksPath at it, which is exactly why they break the moment that setting is overridden somewhere else.

If that didn’t work

• Run GIT_TRACE=1 git commit -m test and read which hook path Git tries to execute.
• Check for a core.hooksPath in the repository's own .git/config — it beats the global value.
• In a worktree, confirm core.hooksPath was not set with --worktree, where the main checkout will not see it.
• Confirm your Git is 2.9 or newer; core.hooksPath does not exist before that.

How to stop it happening again

• Keep hooks in a tracked directory and set core.hooksPath from a setup script, so new clones get them.
• Set the executable bit with git update-index --chmod=+x so it survives cloning.
• Add .husky/** text eol=lf to .gitattributes so Windows never breaks the shebang.
• Enforce the same checks in CI — a hook is a convenience, not a guarantee, because anyone can pass --no-verify.

Commands used in this guide

Frequently asked questions