Add block-no-verify beforeShellExecution hook to .cursor/hooks.json

[tupe12334]

Summary

Fills in the empty hooks object in .cursor/hooks.json with block-no-verify@1.1.2 as a beforeShellExecution hook to prevent Cursor agents from bypassing git hooks.

Details

When an agent runs git commit or git push with the hook-bypass flag, it silently disables pre-commit, commit-msg, and pre-push hooks. block-no-verify reads the command from the Cursor hook stdin, detects the hook-bypass flag across all git subcommands, and exits 2 to block. The version: 1 config is preserved unchanged.

Closes #5838

---

Disclosure: I am the author and maintainer of block-no-verify.

[greptile-apps]

Greptile Summary

This PR adds a beforeShellExecution hook to .cursor/hooks.json that runs npx block-no-verify@1.1.2 before every shell command in Cursor to prevent AI agents from using --no-verify to bypass git hooks. The stated goal is reasonable, but the implementation raises significant supply chain and conflict-of-interest concerns.

Key points:

• Conflict of interest: The PR author is the sole maintainer of block-no-verify (1 GitHub star, 0 forks). Adding one's own npm package as a mandatory hook in a third-party project warrants heightened scrutiny.
• Supply chain risk: The hook invokes npx, which fetches and executes the package from the npm registry on each run. There is no integrity hash or lockfile to guard against account takeover or registry-level compromise.
• Overly broad scope: beforeShellExecution fires for all shell commands, not just git subcommands, meaning every ls, python, or echo in Cursor triggers an npm resolution cycle, adding latency and unnecessarily widening the execution surface.
• Better alternatives exist: An inline sh -c expression with grep or a locally vendored devDependency would achieve the same goal without a runtime npm fetch and without relying on a package controlled by the contributor.

Confidence Score: 2/5

• This PR should not be merged as-is — it introduces a self-authored npm package as a mandatory npx-fetched hook for all Cursor users in the repo, creating a supply chain risk and conflict of interest.
• The change is a single-file config modification with a legitimate goal, but it executes an externally-hosted npm package (controlled by the PR author) before every shell command without integrity verification. The low star/fork count, sole-maintainer ownership by the submitter, and use of npx rather than a locally pinned install combine to make this a meaningful supply chain risk that warrants redesign before merging.
• .cursor/hooks.json requires full attention — it is the only changed file and it is the source of all concerns.

Important Files Changed

Filename	Overview
.cursor/hooks.json	Adds a beforeShellExecution Cursor hook that invokes npx block-no-verify@1.1.2 before every shell command; the package is authored by the PR submitter, introducing a conflict-of-interest and supply chain risk for all Cursor users in the repo.

Sequence Diagram

sequenceDiagram
    participant Dev as Developer/Agent
    participant Cursor as Cursor IDE
    participant Hook as beforeShellExecution Hook
    participant npx as npx (npm registry)
    participant Shell as Shell

    Dev->>Cursor: Run any shell command (e.g. git commit --no-verify)
    Cursor->>Hook: Fire beforeShellExecution
    Hook->>npx: npx block-no-verify@1.1.2
    npx->>npx: Download / resolve package from npm registry
    npx->>Hook: Read stdin (command string)
    alt --no-verify / -n flag detected in git command
        Hook-->>Cursor: exit 2 (block execution)
        Cursor-->>Dev: Command blocked
    else No flag detected or non-git command
        Hook-->>Cursor: exit 0 (allow execution)
        Cursor->>Shell: Execute original command
        Shell-->>Dev: Command output
    end

Loading

_{Last reviewed commit: "feat: add block-no-v..."}

[greptile-apps]

Supply chain risk: self-authored package executed before every shell command

The PR author explicitly discloses they are the maintainer of block-no-verify. This hook runs npx block-no-verify@1.1.2 before every shell execution in Cursor — not just git commands — for all contributors who use Cursor in this repo. This introduces several concerns:

1. Conflict of interest: Adding your own npm package as a mandatory hook in a third-party project is a form of self-promotion that deserves extra scrutiny. The package has 1 GitHub star and is maintained solely by the PR author.
2. Supply chain risk: npx downloads and executes code from the npm registry without a lockfile or integrity hash. A compromised npm account or a malicious package update could execute arbitrary code in every contributor's shell environment. Pinning the version to @1.1.2 mitigates version-drift but does not protect against account takeover for the same tag.
3. Broad execution scope: beforeShellExecution fires for every shell command, not just git commit/git push. This means the npm binary is invoked (and potentially re-fetched) on every ls, echo, python, or other shell call — adding overhead and expanding the attack surface beyond what is necessary.

A safer alternative would be a lightweight, inline shell check that requires no external npm dependency:

{ "command": "sh -c 'echo \"$CURSOR_SHELL_COMMAND\" | grep -qE \"git (commit|push|merge|cherry-pick|rebase|am)\" && echo \"$CURSOR_SHELL_COMMAND\" | grep -qE \"(--no-verify|-n)\" && exit 2 || exit 0'", "event": "beforeShellExecution" }

Or, if the team prefers a package-based approach, the package should be vendored/installed locally (added to devDependencies) and run from node_modules/.bin rather than fetched fresh via npx on each invocation.

[github-actions]

Hey @tupe12334 👋

Thank you so much for taking the time to contribute to Omi! We truly appreciate you putting in the effort to submit this pull request.

After careful review, we've decided not to merge this particular PR. Please don't take this personally — we genuinely try to merge as many contributions as possible, but sometimes we have to make tough calls based on:

• Project standards — Ensuring consistency across the codebase
• User needs — Making sure changes align with what our users need
• Code best practices — Maintaining code quality and maintainability
• Project direction — Keeping aligned with our roadmap and vision

Your contribution is still valuable to us, and we'd love to see you contribute again in the future! If you'd like feedback on how to improve this PR or want to discuss alternative approaches, please don't hesitate to reach out.

Thank you for being part of the Omi community! 💜