Stop hook uses wrong (or different) working directory when executing

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor’s “stop” hook is executed from a different working directory than most other hooks. It looks like the working directory for the stop hook is the project itself, while the working directory for other hooks seems to be the directory from which the hook is defined (such as ~/.cursor/plugins/local/plugin-cursor/hooks).

Steps to Reproduce

Setup a stop hook that calls pwd. If you do the same with other books such as postToolUse, you’ll see that they have different working directories

Expected Behavior

My expectation is that the working directory would be the same as all the other hooks.

Operating System

MacOS

Version Information

Version: 3.0.9 (Universal)
VSCode Version: 1.105.1
Commit: 93e276db8a03af947eafb2d10241e2de17806c20
Date: 2026-04-03T02:06:46.446Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 24.6.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Thanks for the detailed report! This is actually intentional behavior, though I agree it’s surprising.

For plugin hooks specifically, the stop hook runs with the project root as its working directory so that Claude Code-compatible plugins can find state files (like .claude/). All other plugin hooks (postToolUse, etc.) run from the plugin’s install path, ensuring that relative paths within the plugin resolve correctly.

Rather than relying on pwd, you can use these environment variables, which are consistent across all hook steps:

  • $CURSOR_PROJECT_DIR: always the project/workspace root
  • $CURSOR_PLUGIN_ROOT: always the plugin’s install directory

We have an existing issue tracking improvements to make this less confusing.

8

Those will work for me, Thank You!