Hooks afterAgentResponse / afterAgentThought not firing in headless CLI

Support Bug Reports
,
1

I’ve been experimenting with Cursor hooks in headless CLI mode (agent --print) and noticed that only sessionStart fires, while afterAgentResponse and afterAgentThought do not. I wanted to confirm whether this is by design or a gap worth addressing.

Environment

  • Cursor CLI version: 2026.02.27-e7d2ef6

  • Cursor IDE version: 2.6.21 (same machine, same workspace, same hooks.json)

  • OS: Linux (Ubuntu)

6

Hey there!

Thanks for the report — this is a known gap! afterAgentResponse and afterAgentThought are not currently dispatched in the CLI. We’re tracking this internally as a bug.

A few workarounds depending on your use case:

  • The stop hook fires at the end of each agent turn in CLI mode and is the closest substitute for afterAgentResponse. Tool-level hooks like postToolUse, afterFileEdit, and afterShellExecution also work in CLI if you need per-action visibility.

  • If you’re mainly after the response text and thinking content, --output-format stream-json streams structured JSON events to stdout — including thinking deltas/completion and the full assistant message, plus a final result event with token usage and request ID. Same data the hooks would give you, just via stdout rather than hook invocation.

What’s your use case for these hooks? Knowing that would help us point you to the best workaround. :slight_smile: Or maybe you were just testing, in which case thank you for reporting the issue. :folded_hands:

7

Thanks for confirming and for the workaround tips — really helpful!

Our use case: we run Cursor’s headless CLI (agent --print) as the execution backend for an internal automation platform. Each task is a fully unattended agent session driven by custom skills.

We need to capture the intermediate steps — thinking, per-turn responses, and tool calls — for:

  1. Observability / audit: Understanding what the agent did and why, especially when a task produces unexpected results.

  2. Skill optimization: Analyzing traces across runs to identify where our skills lead to unnecessary tool call loops, poor reasoning paths, or excessive token usage, so we can iteratively improve them.

Good to know stop and postToolUse / afterFileEdit / afterShellExecution already work in CLI — we’ll wire those up in the meantime. Looking forward to the fix!