Where does the bug appear (feature/product)?
Cursor CLI
Describe the Bug
cursor-agent (Windows): imported Claude Code hooks are composed as PowerShell but executed with bash, silently blocking every tool call
Describe the Bug
On Windows, Cursor imports hooks from Claude Code’s config when no Cursor hook
config exists. It then wraps each imported hook command in a PowerShell
preamble, but evaluates the resulting string with bash. Every imported hook
therefore dies on a bash syntax error — and because a hook that errors blocks
the tool call, cursor-agent cannot edit files or run shell commands at all.
It still exits 0 and emits a clean result event, so in print mode the
failure is completely silent. The agent reads, reasons, and reports success
while every action it took was rejected.
Steps to Reproduce
- Windows 11 with Claude Code installed and at least one
PreToolUsehook in
~/.claude/settings.json. - No
~/.cursor/hooks.json, no project-level.cursor/hooks.json. - In an empty git repo:
cursor-agent -p "Create a file named hi.txt containing hello. Nothing else." `
--output-format stream-json --trust --force --model auto > out.jsonl
Test-Path hi.txt
Expected Behavior
hi.txt is created.
Actual Behavior
hi.txt is never created. Exit code is 0, stderr is empty, and the stream
contains tool_call/completed entries carrying rejections — both
editToolCall and shellToolCall:
"rejected": {
"reason": "Hook blocked with message: --: eval: line 1: syntax error near unexpected token `&'
--: eval: line 1: `$OutputEncoding = [System.Text.Encoding]::UTF8; Get-Content -LiteralPath
'C:\\Users\\<user>\\AppData\\Local\\Temp\\cursor-hooks-GwQsZg\\payload.json' -Raw
| & { $input | npx -y context-mode hook cursor pretooluse }'
Agent note: Do not suggest workarounds to the blocked tool."
}
The command being evaluated is PowerShell ($OutputEncoding, Get-Content -LiteralPath, | & { $input | ... }), and the error is bash’s
(eval: line 1: syntax error near unexpected token). The cursor-hooks-XXXXXX
temp directory in that path is created by Cursor itself, so the PowerShell
wrapper is Cursor’s own composition — not anything the user wrote.
Why the hooks are Claude Code’s
Nothing was ever registered on the Cursor side. Cursor’s hook log states the
resolution order and the outcome:
User config path: c:\Users\<user>\.cursor\hooks.json
Claude user config path: c:\Users\<user>\.claude\settings.json
No user hooks configuration found <- no Cursor hook config exists
Loaded Claude user hooks <- Claude Code's are adopted instead
(%APPDATA%\Cursor\logs\<timestamp>\window1_wb1\output_<timestamp>\cursor.hooks.workspaceId-*.log)
cursor-agent does the same — its bundle carries claudeUserHooks,
claudeProjectHooks and claudeProjectLocalHooks.
The two hooks blocking everything on this machine were rtk hook claude (a
PreToolUse entry in ~/.claude/settings.json) and
npx -y context-mode hook cursor pretooluse (contributed by a Claude Code
plugin). Both are perfectly valid Claude Code hooks. Neither was written for
Cursor.
Impact
Any Windows user with Claude Code hooks configured has a cursor-agent that
can read and reason but silently cannot act — with no error, no non-zero exit,
and nothing in stderr. In an automated harness this is worse than a crash: the
agent step “succeeds” and the next step fails for an unrelated-looking reason
(nothing to commit, working tree clean). It took two days to trace, and the
symptom points away from the cause at every step.
There is also no obvious off-switch: cursor-agent has no
CLAUDE_CONFIG_DIR support, and I could find no setting to disable the Claude
hook import.
Suggested Fix
- Execute the PowerShell-composed command with PowerShell, or compose a
bash-compatible command when executing with bash. - Separately: a hook that fails to execute is arguably different from a hook
that denies a tool call. Right now a broken hook silently becomes a
full-deny. A hook that cannot run at all could be surfaced as an error
rather than as a rejection with"Do not suggest workarounds to the blocked tool." - A documented way to opt out of importing Claude Code hooks would help
regardless.
Workaround (for anyone who finds this)
Give cursor-agent a home directory containing your real .cursor and no
.claude:
$fh = "$env:TEMP\cursor-clean-home"
New-Item -ItemType Directory -Force $fh | Out-Null
cmd /c mklink /J "$fh\.cursor" "$env:USERPROFILE\.cursor" # no elevation needed
$env:USERPROFILE = $fh; $env:HOME = $fh
The junction keeps authentication working. Verified: 3 rejections and no file
written → 0 rejections and the file created.
If you later delete that scratch directory, remove the junction with
cmd /c rmdir "$fh\.cursor" first — a recursive delete that follows junctions
would walk into your real Cursor config.
Environment
- OS: Windows 11 Enterprise 10.0.26200
- cursor-agent:
2026.08.11-e8db854(also reproduced on2026.08.04-aaa8809) - Flags:
-p --output-format stream-json --trust --force --model auto - Config:
approvalMode: allowlist,sandbox.mode: disabled - Not shell-dependent: reproduced from PowerShell with
SHELLnot exported,
and with a clean WindowsPATH. The launching shell makes no difference — I
chased that first and it was a dead end.
Does this stop you from using Cursor?
Yes for headless/automated use on Windows. Interactive use is affected too, but
there a user notices the rejections; in print mode nothing surfaces at all.
Steps to Reproduce
- Windows 11 with Claude Code installed and at least one
PreToolUsehook in
~/.claude/settings.json. - No
~/.cursor/hooks.json, no project-level.cursor/hooks.json. - In an empty git repo:
cursor-agent -p "Create a file named hi.txt containing hello. Nothing else." `
--output-format stream-json --trust --force --model auto > out.jsonl
Test-Path hi.txt
Expected Behavior
hi.txt is created.
Operating System
Windows 10/11
Version Information
- OS: Windows 11 Enterprise 10.0.26200
- cursor-agent:
2026.08.11-e8db854(also reproduced on2026.08.04-aaa8809) - Flags:
-p --output-format stream-json --trust --force --model auto - Config:
approvalMode: allowlist,sandbox.mode: disabled - Not shell-dependent: reproduced from PowerShell with
SHELLnot exported,
and with a clean WindowsPATH. The launching shell makes no difference — I
chased that first and it was a dead end.
Does this stop you from using Cursor
Yes - Cursor is unusable