A developer writes a secret-scanning hook for one repository and defines it in the home directory hooks file. Colleagues who copied the setup now report it firing while they work on unrelated projects and blocking commands there. What is the right correction?

Hardcursorhooksconfiguration

Last reviewed 21 Aug 2026

Define it in that repository's .cursor/hooks.json and commit it, because project hooks apply to that project alone while home directory hooks apply to every project you open.Correct answer
Keep the single home directory file, since Cursor reads one hooks configuration per machine, and add a matcher so that the hook only fires while files inside that repository are involved.
Leave the definition where it is and lean on workspace trust, because an untrusted workspace already stops any home directory hook from running against the files it contains.
Move it to the enterprise configuration directory, which is the source scoped to a single repository and takes precedence over both the user and the project definitions during merge.

Show answer & explanation

Correct answer: A. Define it in that repository's .cursor/hooks.json and commit it, because project hooks apply to that project alone while home directory hooks apply to every project you open.

Explanation

The principle — Hooks load from four sources: enterprise configuration managed by MDM, team configuration distributed from the dashboard, a project's .cursor/hooks.json, and your own ~/.cursor/hooks.json. Every matching hook from every source runs, and where responses conflict the higher-priority source wins the merge, in the order enterprise, team, project, user. Scope is decided by the file the hook lives in: project-level hooks apply only to that specific project, while home directory hooks apply globally.

Why the key is correct — A scanner meant for one repository belongs in that repository. Committing .cursor/hooks.json gives it exactly the reach it should have, and it arrives with the code for everyone who clones it, including cloud agents working on that repo. Two details come with the move. Project hooks run from the project root, so a command written as ./hooks/scan.sh for the home directory becomes .cursor/hooks/scan.sh once committed, and forgetting this leaves a hook that fails to launch. Project hooks also require a trusted workspace, which is the same mechanism seen from the other side: cloning someone's repository and trusting the workspace runs their hook scripts on your machine, so a hooks file is worth reading before you trust an unfamiliar repo.

Why the others are wrong — There is no single hooks file; the location is the scoping mechanism, and a matcher narrows by command or tool rather than by project, so it cannot express repository boundaries. Workspace trust governs whether a repository's own hooks may run, and it places no limit on the ones you installed for yourself. Moving the file to the enterprise directory pushes the hook to every user on the machine and, being MDM-managed, out of the developer's hands, which is the opposite of narrowing.

Remember this — Where a hook lives is what it applies to. Repository concerns go in the repository; only machine-wide habits belong in the home directory.

Sources — Cursor's Hooks documentation.

Sources

Primary sourceHooks — Cursor · accessed 19 Aug 2026
“Project-level hooks apply only to that specific project, while home directory hooks apply globally.”

Practise 10 questions on this topic

Take Cursor Basics — Timed Test 1 (10 questions) — scored instantly, explanation for every question, no login.

Start the test

A developer writes a secret-scanning hook for one repository and defines it in the home directory hooks file. Colleagues who copied the setup now report it firing while they work on unrelated projects and blocking commands there. What is the right correction?

Related questions

A developer writes a secret-scanning hook for one repository and defines it in the home directory hooks file. Colleagues who copied the setup now report it firing while they work on unrelated projects and blocking commands there. What is the right correction?

Related questions