What problem does it solve?
Cursor hooks let you add guardrails, auditing, and automated follow-up behavior around agent and tool events, but designing them correctly requires knowing the right event, the correct hooks.json structure, and where project vs user hooks must live.
Core Features & Use Cases
- Hook-driven automation around agent events: Create logic that runs before or after events like tool use, shell execution, file reads, and prompt submission.
- Command and prompt hook support: Build deterministic command hooks that exchange JSON via stdin/stdout or use prompt hooks for simpler policy decisions.
- Scoped placement with correct path semantics: Use project hooks under
.cursor/ for repo-shared behavior and user hooks under ~/.cursor/ for personal behavior, ensuring paths resolve properly.
- Matcher-based targeting and safety controls: Narrow hook execution with matchers (JavaScript-style regex) and decide whether failures should fail open or fail closed using
failClosed.
Quick Start
Ask your agent to create or update a .cursor/hooks.json hook that blocks potentially risky shell commands by adding a matcher for network tools and implementing the corresponding hook script under .cursor/hooks/, returning allow/deny permissions based on the stdin JSON payload.