Cursor CLI AskQuestion tool skips preToolUse and postToolUse hooks

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

When the agent invokes the AskQuestion tool, none of the documented hook
events fire for that tool call
. preToolUse and postToolUse are documented
to fire for all tools, but AskQuestion is excluded — in the same session
where Shell calls fire the full event sequence correctly.

This appears to be the same root cause as the already-acknowledged IDE bug
AskQuestion tool does not trigger cursor hooks
(closed for inactivity), but reproduced specifically in the CLI, with a
2026.05.28 build, so it likely needs a separate fix path even when the IDE
fix lands.

Steps to Reproduce

  1. Register a capture.sh hook on every documented event in
    ~/.cursor/hooks.json (full file at the bottom of this report). The script
    appends argv, CURSOR_* env vars, and stdin to a single log file.
  2. Restart cursor-agent so the new hooks.json is loaded.
  3. In the agent, run a single Shell call (e.g. ask for echo hello). Hooks
    fire correctly — preToolUse and postToolUse are logged with
    "tool_name":"Shell".
  4. In the same session, have the agent invoke the AskQuestion tool. Answer
    the question.
  5. Run another Shell call and re-read the log.

Result: AskQuestion produces zero hook invocations between the
surrounding Shell invocations.

Captured event timeline (UTC)

This is from a single live session. The agent (a) ran a Shell call, (b)
invoked AskQuestion and got an answer, (c) ran another Shell call. Only
(a) and (c) show up in hook events:

2026-05-28T19:40:13Z  beforeSubmitPrompt     tool=-
2026-05-28T19:40:24Z  preToolUse             tool=Shell      ← Shell call (a)
2026-05-28T19:40:24Z  beforeShellExecution   tool=-
2026-05-28T19:40:25Z  afterShellExecution    tool=-
2026-05-28T19:40:25Z  postToolUse            tool=Shell
                                                              ← (b) AskQuestion
                                                                fired and was
                                                                answered between
                                                                these two Shell
                                                                calls, but
                                                                produced NO hook
                                                                events at all
2026-05-28T19:40:46Z  preToolUse             tool=Shell      ← Shell call (c)
2026-05-28T19:40:46Z  beforeShellExecution   tool=-
2026-05-28T19:40:46Z  afterShellExecution    tool=-
2026-05-28T19:40:47Z  postToolUse            tool=Shell

Event counts for the session:

3 preToolUse           ← all three are Shell
3 beforeShellExecution
2 postToolUse          ← both are Shell
2 afterShellExecution
1 beforeSubmitPrompt
0 — every other registered event, including any AskQuestion-related one

The only "tool_name" value present anywhere in the captured payloads is
"Shell". AskQuestion, ask_question, AskUserQuestion, etc. appear
nowhere as tool_name (or any other identifying field).

Expected Behavior

Per the hooks documentation:

preToolUse / postToolUse / postToolUseFailure - Generic tool use hooks
(fires for all tools)

The AskQuestion tool should fire at least preToolUse and postToolUse,
with a stable tool_name value, so:

  • third-party observability can audit human-in-the-loop gates,
  • agents can’t bypass approval flows by claiming consent that wasn’t given,
  • notifier integrations can react to “agent is now waiting on the user”.

Operating System

MacOS

Version Information

cursor-agent: 2026.05.28-418efe5
cursor (IDE): 3.4.20
macOS: 26.5 (build 25F71)
uname: Darwin 25.5.0 arm64
tmux: 3.6a
python3: 3.9.6 (system)

Additional Information

Appendix A: ~/.cursor/hooks.json

Capture hook is registered against every event listed at hooks documentation

{
  "version": 1,
  "hooks": {
    "stop": [{ "command": "./hooks/capture.sh stop" }],
    "beforeSubmitPrompt": [{ "command": "./hooks/capture.sh beforeSubmitPrompt" }],
    "beforeShellExecution": [{ "command": "./hooks/capture.sh beforeShellExecution" }],
    "afterShellExecution": [{ "command": "./hooks/capture.sh afterShellExecution" }],
    "sessionStart":       [{ "command": "./hooks/capture.sh sessionStart" }],
    "sessionEnd":         [{ "command": "./hooks/capture.sh sessionEnd" }],
    "preCompact":         [{ "command": "./hooks/capture.sh preCompact" }],
    "preToolUse":         [{ "command": "./hooks/capture.sh preToolUse" }],
    "postToolUse":        [{ "command": "./hooks/capture.sh postToolUse" }],
    "postToolUseFailure": [{ "command": "./hooks/capture.sh postToolUseFailure" }],
    "subagentStart":      [{ "command": "./hooks/capture.sh subagentStart" }],
    "subagentStop":       [{ "command": "./hooks/capture.sh subagentStop" }],
    "beforeMCPExecution": [{ "command": "./hooks/capture.sh beforeMCPExecution" }],
    "afterMCPExecution":  [{ "command": "./hooks/capture.sh afterMCPExecution" }],
    "beforeReadFile":     [{ "command": "./hooks/capture.sh beforeReadFile" }],
    "afterFileEdit":      [{ "command": "./hooks/capture.sh afterFileEdit" }],
    "afterAgentResponse": [{ "command": "./hooks/capture.sh afterAgentResponse" }],
    "afterAgentThought":  [{ "command": "./hooks/capture.sh afterAgentThought" }]
  }
}

Appendix B: capture.sh

#!/bin/bash
# Diagnostic capture hook. Logs every Cursor hook invocation to one file
# so we can see WHICH events actually fire when the agent uses AskQuestion.
set -u
LOG="${TMPDIR:-/tmp}/cursor-hook-capture.log"
ts=$(date -u +'%Y-%m-%dT%H:%M:%SZ')
{
  printf '===== %s =====\n' "$ts"
  printf 'argv: %s\n' "$*"
  env | awk '/^CURSOR_/ {print "env: " $0}'
  echo '--- stdin ---'
  head -c 4096
  printf '\n--- end stdin ---\n\n'
} >> "$LOG" 2>&1
exit 0

Related

  • Forum thread (IDE-acknowledged, closed for inactivity):
  • Cursor staff (deanrie) acknowledged in that thread:

    It looks like this is a bug. The docs say preToolUse and postToolUse
    run for all tools, so AskQuestion should be included too. I’m passing
    this on to the team.

The fix presumably needs to land on both the IDE adapter and the CLI hook
adapter for the AskQuestion tool.

Does this stop you from using Cursor

No - Cursor works, but with this issue

This is a confirmed bug. The AskQuestion tool is not wired to fire preToolUse/postToolUse hooks in either the IDE or the CLI. Your methodology and event timeline are excellent confirmation.

No workaround exists for this specific tool at the moment. Our team is aware and this is tracked internally. I’ll update this thread when there’s progress.

I just hit this in Cursor **3.9.16** (July 2026) and did a deep investigation that confirms it’s still broken — and worse than the original report suggests. Sharing concrete evidence in the hope this gets prioritized.

## What I tested

I’m building an ESP32 status light that mirrors Cursor agent state via hooks. For the integration to work I need to know when the agent is **waiting for user input** (AskUserQuestion, permission prompts, elicitation). I tested every signal Cursor exposes.

## Findings — three independent ways this is broken

### 1. AskUserQuestion fires zero hooks

I instrumented `~/.cursor/hooks/agentcore-light.sh` to log every payload it receives, then called AskUserQuestion multiple times from inside an agent conversation.

**Result:** Zero hook invocations across `preToolUse`, `postToolUse`, `postToolUseFailure`, `afterAgentResponse`, `Notification`, `stop`. The Cursor internal hook log at `~/Library/Application Support/Cursor/logs/…/cursor.hooks.*.log` shows no “Hook step requested” entries during the call.

The agent clearly transitions to a UI-waiting state (the dialog appears), but the hook system is never told.

### 2. `matcher` field is silently ignored

Per the docs, `preToolUse` accepts a `matcher` to filter by tool name. I tried:

```json

“preToolUse”: [

{ “command”: “sh ./hook.sh”, “matcher”: “AskUserQuestion” }

]

```

Cursor **does not error**, but the matcher is silently dropped — log shows `Found 1 hook(s) to execute` regardless of tool name, and the hook never fires for AskUserQuestion. So even if AskUserQuestion *did* emit a preToolUse event, the documented matcher API doesn’t gate on it.

### 3. `Notification`, `PermissionRequest`, `Elicitation` are rejected as unknown hook types

Hoping these events would still fire on permission/elicitation flows (the other “agent is waiting” cases), I added them to `hooks.json`. Cursor fails to load the config:

```

ERROR: Invalid user config: Unknown hook type: Notification. Valid types are:

beforeShellExecution, beforeMCPExecution, afterShellExecution, afterMCPExecution,

beforeReadFile, afterFileEdit, beforeTabFileRead, afterTabFileEdit, stop,

beforeSubmitPrompt, afterAgentResponse, afterAgentThought, sessionStart,

sessionEnd, preCompact, subagentStart, subagentStop, preToolUse, postToolUse,

postToolUseFailure, workspaceOpen

```

The “waiting for user” surface area in Cursor IDE has **no hook coverage at all**. Compare to Claude Code v2.1.85+ where `preToolUse` with `matcher: “AskUserQuestion”` was explicitly fixed (referenced in [anthropics/claude-code#10168]( Add hook for user input/question events (UserInputRequired) · Issue #10168 · anthropics/claude-code · GitHub )) — that fix hasn’t propagated to the Cursor IDE.

## Why this matters more than “I want a notification”

This isn’t a niche integration concern. The hook documentation explicitly says `preToolUse`/`postToolUse` “fires for all tools.” That contract is broken for one of the most important tools in the agent lifecycle — the one where a human is in the loop.

Concrete impact:

- **Physical/distributed status displays can’t show “agent needs me”** — ESP32 lights, Slack pings, mobile push, terminal bells all rely on hooks as the only event source. Right now, when an agent asks me a question, my status light shows the same “agent is thinking” pattern as before. I cannot distinguish “Claude is working” from “Claude is waiting for me to answer.” That defeats the entire point.

- **Human-in-the-loop approval gates cannot be enforced.** If a hook can’t observe AskUserQuestion or permission prompts, third-party governance/compliance tools cannot verify that a human actually answered. As [previously noted]( Cursor CLI AskQuestion tool skips preToolUse and postToolUse hooks ), this means agents can claim consent they never got — a real auditability problem.

## What I’d like to ask

1. Confirm this is still on the active bug list (the previous thread was auto-closed for inactivity in April, reposted in May, acknowledged — but no movement since).

2. Is there a timeline? Even a rough one (“next quarter” / “not before v4.x”) would let me decide whether to ship a workaround now or wait.

3. If a fix is being scoped, please also include `Notification` / `PermissionRequest` / `Elicitation` as first-class hook types in Cursor IDE (not just Claude Code). The IDE has zero hook coverage for “agent is waiting on me” right now.

Happy to provide more reproduction detail, hook logs, or a minimal repro repo if helpful.