Yes. Git hooks are programs that Git runs at certain points, such as before a commit, and they run as you. By default they live in the hooks folder inside the repository's Git directory, and a configuration variable can point Git at a different folder. Review any hook setup before you adopt it.
What the documentation says
The githooks manual describes hooks as programs you can place in a hooks directory to trigger actions at certain points in Git's execution. Hooks without the executable bit set are ignored. By default the directory is the hooks folder under the Git directory, but the core.hooksPath configuration variable can change it.
That second part is the one to know. A team that wants shared hooks usually sets the hooks path to a folder tracked in the repository, so everyone runs the same checks.
Why the shared setup deserves a look
A shared hook folder is convenient and also a place where executable code sits in a repository you may not have read. Common ways it gets adopted:
- A setup script or a package install step sets the hooks path for you.
- A README tells you to run a one line command that does it.
- A tool that manages hooks installs its own scripts and keeps them updated.
Each of those is reasonable. Each is also a way for a change in someone else's repository to run on your machine at your next commit.
A review checklist
- Open the hooks folder and read the scripts. They are usually short.
- Check what the hook calls out to. A hook that downloads and runs something at commit time deserves scrutiny.
- Check how the hooks path got set, with git config and the show origin option, so you know whether a project level setting changed it.
- Pin the versions of any tool a hook manager installs.
- Re-read the hook folder after pulling changes to it, the same way you would a CI workflow change.
Bypassing and why it matters
The manual notes that some hooks can be bypassed with the no verify option on certain commands. That means hooks are a convenience and a guardrail for honest mistakes, not a control that stops a determined person. Anything you need to enforce, such as blocking a vulnerable dependency, belongs in a server side check or a pull request gate, not only in a local hook.
A good use for hooks
Local hooks work well for fast, low risk feedback: formatting, a quick lint, a check that a lockfile changed together with package.json. Keep them quick and dependency free, so they are easy to read and hard to abuse.
If you want a quick look at what your projects actually resolve, Safeguard offers SBOM and dependency scanning, and there is a free scan at gold.safeguard.sh/scan.
Click through it at your own pace, or open it full screen.
Quick check
Where do hooks live by default?
In the hooks folder under the repository's Git directory. The core.hooksPath variable can point somewhere else.
Are local hooks a security control?
Not on their own. Some can be bypassed, so enforce important rules in the pull request or server side as well.
Sources
Last reviewed: 19 October 2026.
