Cursor introduces hooks

The Simplest Way to Create and Launch AI Agents and Apps

You know that AI can help you automate your work, but you just don't know how to get started.

With Lindy, you can build AI agents and apps in minutes simply by describing what you want in plain English.

From inbound lead qualification to AI-powered customer support and full-blown apps, Lindy has hundreds of agents that are ready to work for you 24/7/365.

Stop doing repetitive tasks manually. Let Lindy automate workflows, save time, and grow your business.

Get $20 Worth of Free Credits

Cursor has now finally introduced hooks, a system for running external programs/commands during key points of the agent loop. Each hook receives structured JSON over stdin and can decide whether to allow or deny the action, modify data, or run side effects. This makes it possible to block unsafe shell commands, redact tokens before content leaves your machine, run formatters automatically, and checkpoint work into commits.

This makes Cursor and the workflows it carries out a bit more deterministic and brings it a bit closer to Claude Code featureset.

Where and how to define hooks?

Hooks can be defined in multiple locations, and Cursor runs all that apply. Common scopes are:

• .cursor/hooks.json inside a repo, checked into version control so the whole team sees the same rules.

• ~/.cursor/hooks.json in a user’s home directory for personal automation across projects.

This layering allows a mix of shared guardrails and individual productivity tweaks.

Lifecycle events

Cursor passes structured events to your scripts. A few examples:

• beforeShellExecution and beforeMCPExecution can return JSON to allow, deny, or ask

• beforeReadFile lets you rewrite file content before it goes into a model call

• afterFileEdit provides old and new contents for tasks like formatting or staging

• stop marks the end of a session and is useful for snapshotting work into a commit

Example: blocking -rm/-rf commands for the agent mode

Sample hooks.json file to block -rm/-rf commands

{
  "version": 1,
  "hooks": {
    "beforeShellExecution": [
      {
        "command": "./block-rm.sh"
      }
    ]
  }
}

## block-rm.sh

#!/bin/sh

read payload
cmd=$(echo "$payload" | jq -r .command)

if echo "$cmd" | grep -Eq "rm -rf[[:space:]]*/"; then
  jq -n --arg msg "Blocked rm -rf" \
    '{continue:false, permission:"deny", userMessage:$msg}'
else
  jq -n '{continue:true, permission:"allow"}'
fi

Drop this script in .cursor/hooks/, run chmod +x .cursor/hooks/*.sh, and the workflow is active.

Practical uses

You can start small with these and gradually expand to take on more complex tasks

• Preventing destructive git commands: intercept git push --force outside main/dev, or auto-prompt confirmation before rebases.

• Commit templating: on stop, enforce conventional commit messages (feat:, fix:, chore:) or attach issue IDs automatically.

• Secret scanning: deny shell commands or file edits that include AWS keys, JWTs, or .pem blobs.

• File filters: block edits to .env or infra configs unless explicitly allowed.

• Code style enforcement: run black, prettier, or gofmt automatically after afterFileEdit.

• Auto-staging snapshots: checkpoint into git stash or git commit --no-verify on every stop.

• Telemetry-free logging: instead of sending data out, pipe event summaries into a local log for later auditing.

• Context sanitization: strip large binary blobs or generated files before passing file context to the model.

• Local test runs: after edits, trigger npm test, pytest, or a subset of fast tests automatically to catch regressions

Can you take a moment to rate this edition? It helps me cater the right content to you.

📱 Stay connected: Follow me on LinkedIn and Twitter/X for daily AI tool breakdowns and quick wins