Cursor 3.15.6 silently disables ALL git hooks for commits made from the Source Control panel (injects `core.hooksPath=/dev/null`)

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor’s bundled git extension force-injects core.hooksPath=/dev/null into the
environment of every git invocation, including commit. Every git hook — pre-commit,
commit-msg, pre-push — is silently skipped when you commit from the Source Control panel.
No error, no output, exit code 0. Stock VS Code does not do this.

Steps to Reproduce

A pre-commit hook that runs a 37-second test suite. Commit from the Source Control panel
finishes in 32 ms. Output → Git shows:

> git -c user.useConfigOnly=true commit --quiet --allow-empty-message --file - [32ms]

Note there is no --no-verify — the command line is clean. Running that exact command line
in a terminal in the same repo runs the hook normally. So it is not the arguments; it is the
environment Cursor passes to the child process.

In Cursor.app/Contents/Resources/app/extensions/git/dist/main.js:

La = [["safe.bareRepository", "explicit"],
      ["core.fsmonitor", "false"],
      ["core.hooksPath", os.devNull],
      ["core.attributesFile", os.devNull]]

These are injected as GIT_CONFIG_KEY_n / GIT_CONFIG_VALUE_n / GIT_CONFIG_COUNT by the
env-building function, which ends with:

return n.command !== void 0 ? e.VSCODE_GIT_COMMAND = n.command
                            : delete e.VSCODE_GIT_COMMAND, Uu(e)

The n.command !== void 0 check only decides whether VSCODE_GIT_COMMAND is set. Uu(e) —
the override injection — runs unconditionally, for every command, commit included.
Because the override travels in the environment rather than as a -c flag, it never shows up
in the logged command line, which makes this very hard to diagnose.

For comparison: in stock VS Code 1.119.0, the string core.hooksPath appears 0 times in
the same extension bundle. This is Cursor-specific.

Operating System

MacOS

Version Information

Version: 3.15.6
VS Code Extension API: 1.128.0
Commit: a1f686545fd0ce8917bbd2449f733551a9bce420
Date: 2026-08-06T01:41:03.876Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.291
OS: Darwin arm64 24.6.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed write-up. The decompilation and your conclusion about the GIT_CONFIG_* env vars are spot on, that’s exactly what’s happening. What you’re seeing isn’t intended behavior, and it’s not something in your setup.

This is an issue we’re already tracking. There are a couple other threads with the same symptom, and I’ll link your report to them. I can’t share an exact timeline yet, but I’ll post here when there’s an update.

For now, the workaround is to commit and push from the integrated terminal. The env with pins isn’t exported to the terminal, so hooks run normally there, which you already noticed in your test.

Also thanks for the note about the clean command line in Output → Git. I passed that to the team, that’s part of why this is so hard to diagnose.

7

Still broken on Cursor v24.15.0 (Linux).

Repro:

  • Repo has a working pre-commit hook (`core.hooksPath=./pipelines`).
  • `git commit` in the integrated terminal → hook runs, commit aborted on lint failure as expected.
  • Commit via Source Control panel → hook never runs; commit succeeds.

This also breaks ISO/compliance workflows that rely on local pre-commit (secret scan, ruff, dependency audit, etc.). Please don’t silently disable hooksPath from the SCM commit button.

Posted by Cursor Agent (AI assistant) on behalf of the user.

8

Hey, thanks for confirming. It’s helpful to know this also reproduces on Linux, so it’s not platform-specific.

This is an issue we’re already tracking. There are details and a root cause write-up in the thread above. In short, pins for core.hooksPath get passed through the environment of the git process used by the Source Control panel, so the hooks get silently skipped. I can’t share an exact timeline yet.

For now, the workaround is to do commit and push from the integrated terminal. Those env pins don’t get forwarded there, so pre-commit, commit-msg, and pre-push run normally, like you’re seeing when you commit from the terminal.

I’ll post here when there’s an update.