Let postToolUseFailure inject additionalContext (Claude PostToolUseFailure parity)

Ideas Feature Requests
,
1

Feature request for product/service

Cursor IDE

Describe the request

Current behavior

Cursor already fires postToolUseFailure when a tool fails, times out, or is denied. Official docs (https://cursor.com/docs/hooks.md) document the event input (error_message, failure_type, duration, is_interrupt) but state that no output fields are currently supported. A hook can observe the failure but cannot inject context back into the agent.

Claude Code’s equivalent event (PostToolUseFailure) accepts hookSpecificOutput.additionalContext, so a hook can tell the agent how to recover — for example, credentials expired → log in, then retry the same tool. Cursor’s third-party hooks mapping (https://cursor.com/docs/reference/third-party-hooks.md) maps PreToolUse / PostToolUse / Stop / etc., but does not map Claude’s PostToolUseFailure.

People sometimes look for this as afterPreToolUseFailure; the Cursor-native name is postToolUseFailure.

Proposed behavior

  1. Accept hook output on postToolUseFailure, at least additionalContext (and/or hookSpecificOutput.additionalContext for Claude parity), so the next agent turn sees recovery instructions.
  2. Map Claude PostToolUseFailure → Cursor postToolUseFailure in third-party hooks, including that output.
  3. Same schema on Cursor IDE and Cursor CLI (hooks.json).

Why it matters

Without output, failure hooks are observational only. Common recovery flows (expired cloud SSO / CLI auth, a permission the user just granted, a transient timeout) cannot tell the agent “retry now.” Teams that share hook scripts across Claude Code and Cursor have to leave the failure-recovery hook unwired on Cursor.

Environment

  • Cursor IDE 3.16.17 (commit 6b2afae0257df2bb5e1835f15165dc2f0de056b0) darwin arm64
  • Cursor CLI agent 2026.07.16-899851b
  • macOS 26.5.2

Related (distinct — not duplicates)

Search

Forum search for #feature-requests postToolUseFailure, afterPreToolUseFailure, and additionalContext hooks returned no matching request.

Operating System (if it applies)

MacOS

5

Hey John!

The native path already does this. A postToolUseFailure hook can return additional_context and it is injected into the agent’s next turn (same carrier as postToolUse). I just verified it.

The “no output fields supported” line in the hooks docs is stale. We’ll get that table updated.

Could you try it on your side and confirm?

7

Confirmed on Cursor IDE 3.17.8 (commit 2fdd31c9, darwin arm64).

Native postToolUseFailure does inject additional_context into the agent’s next turn — same carrier as postToolUse. A canary hook returned:

{"additional_context":"CURSOR_PTUF_CANARY_168652: if you can see this, reply with this exact token."}

after ls /no-such-ptuf-canary-168652 (Shell exit 1). The token arrived on the following model invocation as a system reminder. The failure payload was failure_type: "error" with error_message set to the command stderr (no tool_output / tool_response).

A command whose overall Shell exit was 0 (failed ls then echo EXIT:$?) only fired postToolUse, not postToolUseFailure. Classification follows the Shell tool’s exit code.

Two items from the original request still look open:

  1. Third-party hooks mapping still omits Claude PostToolUseFailure → Cursor postToolUseFailure (https://cursor.com/docs/reference/third-party-hooks.md). A Claude settings.json hook does not run in Cursor; native ~/.cursor/hooks.json is required. Native Cursor wants top-level additional_context; Claude’s nested hookSpecificOutput.additionalContext is a different carrier.

  2. CLI / cloud: the last published CLI hook list (Dean, Apr 12 on the CLI hooks thread) includes postToolUse but not postToolUseFailure. Cloud agents similarly list tool-level hooks without this event.

The public postToolUseFailure output table still says “No output fields currently supported” as of 2026-08-22.

9

Marking this complete.

Native IDE postToolUseFailure already injects additional_context (Colin above; confirmed on 3.17.8). That’s the original request, so I’m accepting that reply as the solution.

Leftovers that are not this FR: the public docs table still says “no output fields,” third-party mapping still omits Claude PostToolUseFailure, and CLI/cloud still don’t list the event.