Feature request for product/service
Cursor IDE
Describe the request
Current behavior
Cursor documents preToolUse (and specialized beforeShellExecution / beforeMCPExecution / beforeReadFile) as the gate before a tool runs. If that hook command crashes, times out, returns invalid JSON, or is canceled, the documented behavior is fail-open (the action proceeds) unless failClosed: true, in which case the action is blocked.
There is no documented hook that fires after that pre-tool hook failure. postToolUseFailure is a different event: it fires when the tool fails, times out, or is denied — not when the hook process itself fails. Its output schema is currently empty (“No output fields currently supported”).
Why this matters
On a failClosed beforeShellExecution security hook, Cursor can cancel the hook before it spawns (Hook execution failed: Canceled: Canceled / host not initialized). With failClosed: true, every subsequent Shell call is then blocked. There is no event a recovery script or the agent can handle to distinguish “policy deny” from “hook infrastructure failed,” inject that distinction into the conversation, or attempt recovery. The workaround is failClosed: false, which means hook crashes silently allow the tool through.
Related bug (not this request): Agent Shell hard-locks: fail-closed beforeShellExecution + MainThreadShellExec not initialized
Proposed behavior
Add an afterPreToolUseFailure event (name is bikeshed-ok) that fires when a pre-tool hook fails for crash / timeout / invalid JSON / cancel / failClosed block, with at least:
- which hook event failed (preToolUse, beforeShellExecution, …)
- failure_type (crash | timeout | invalid_json | canceled | …)
- error_message
- whether the action was blocked (failClosed) or allowed through
Useful outputs (v1 can be observe-only; failClosed should keep blocking):
- additional_context / agent_message so the model sees “hook failed, not policy deny”
Who it hurts
Anyone using failClosed security hooks. Today the choice is hard-lock all tools when the hook host flakes, or fail-open and lose the safety net, with no way to tell the agent what happened.
Why existing topics do not cover this
- Feature-request search for afterPreToolUseFailure, postToolUseFailure, and failClosed preToolUse returned no matching FR.
- Forum hits for postToolUseFailure are bugs (empty conversation_id, AskQuestion skipping hooks, web search not emitting preToolUse) — different symptoms.
- Claude Code’s PostToolUseFailure is not in Cursor’s third-party hook mapping table (https://cursor.com/docs/reference/third-party-hooks.md). Native postToolUseFailure exists but cannot inject context. Those are adjacent gaps; this request is specifically “hook itself failed,” not “tool failed.”
Docs: https://cursor.com/docs/hooks.md (failClosed; postToolUseFailure output: none)
Environment
- Cursor IDE 3.16.17, VSCode Version 1.128.0, Commit 6b2afae0257df2bb5e1835f15165dc2f0de056b0, arm64
- macOS (Darwin 25.5.0)
- CLI agent --version: unknown (not collected this run)
- Request ID: n/a (not an AI-behavior report)
Operating System (if it applies)
MacOS