We added hooks in .cursor to send all events using OTEL to a dedicated observability platform. Looking at the logs we generate, i can see the using the IDE works perfectly for our use case, but when working with cursor-agent (cursor cli), it sends only beforeShellExecution & afterShellExecution. All other events are omitted for some reason.
This is the expected current behavior. Cursor CLI (cursor-agent) has partial hook support right now, and only the beforeShellExecution and afterShellExecution events fire. Full hook parity with the IDE, including beforeSubmitPrompt, afterAgentResponse, afterFileEdit, and so on, is on our roadmap.
Does it mean that Hooks features will be officially supported for Cursor CLI?
Currently, what’s the status of the implementation? What are the way to configure it, is it exactly same as Cursor IDE? I can’t find anything about Cursor CLI Hooks in docs…
Hook support in the CLI has expanded. These hooks now work in the CLI: beforeShellExecution, afterShellExecution, afterFileEdit, postToolUse, stop, and sessionStart. The afterAgentResponse and afterAgentThought hooks still don’t work in the CLI, the team knows about this gap.
For --print mode there’s a useful workaround: the --output-format stream-json flag streams structured JSON events to stdout, including thinking deltas, the full assistant message, and a final result event with token usage and the request ID. It’s basically the same data you’d get from hooks, just via stdout.
In the local CLI, afterAgentResponse and afterAgentThought still aren’t firing. Nothing’s changed since April. For cloud agents it’s broader. None of the lifecycle hooks fire at all (sessionStart, sessionEnd, afterAgentResponse, stop). Only tool-level hooks work (preToolUse, postToolUse, beforeShellExecution, afterShellExecution, beforeReadFile, afterFileEdit). We’re tracking the cloud gap separately, but I can’t share an ETA yet.
If your main use case is observability on cloud agents, can you share which events are critical, like the full assistant message, thinking, token usage, a request ID on completion? That’ll help the team prioritize and suggest a temporary workaround for your pipeline. If you’re running a cloud agent via the API, the final response already includes some of this data, but I’m not sure it covers everything you need.
This message was AI generated with what we are trying to achieve:
Our use case is exactly that: observability on cloud agents, piped into Langfuse. We already get full per-turn traces from our Claude Code agents via its native OpenTelemetry export (prompt, assistant message, token usage, request ID, stop reason), and we’re trying to get cloud Cursor agents to parity so both pipelines land in the same place. The tool-level hooks that do fire in cloud are great for the shell/file/tool spans, but on their own they give us the actions without the reasoning, cost, or a clean trace boundary.
Ranked by how much it unblocks us:
P0 — can’t close a usable trace without these:
Final assistant message (the afterAgentResponse/completion text) — this is the single most important one; it’s how we reconstruct what the agent concluded and did.
A completion/stop signal with final status (completed | aborted | error) — we need something that marks the trace as done, since stop/sessionEnd don’t fire.
Token usage — input / output / and ideally cache-read + cache-creation. This is for cost attribution; without it cloud runs are a cost blind spot.
Provider request ID(s) on completion — to correlate/dedupe against the model provider and our own logs.
P1 — valuable:
The submitted prompt (beforeSubmitPrompt) — to see what the agent was actually asked.
Thinking/reasoning (afterAgentThought).
The full system prompt — to capture exactly which instructions the agent ran under.
One note on the API suggestion: we don’t drive these via the cloud-agent API directly — they’re kicked off through Linear’s Cursor delegation (issue → agent), so the API’s final-response payload isn’t in our path today. Happy to test anything behind a flag.
Thanks for the detailed breakdown. That ranked P0/P1 list is exactly what the team needs, I’ll share it as-is.
Status on cloud agents hasn’t changed since my update above: in cloud, only tool-level hooks fire right now (preToolUse, postToolUse, beforeShellExecution, afterShellExecution, beforeReadFile, afterFileEdit). Lifecycle events (afterAgentResponse, stop, sessionStart, sessionEnd) don’t fire. So your P0 items (final assistant message, completion signal, token usage, request ID) can’t be captured via hooks in cloud at the moment. We’re tracking this gap, but I can’t share an ETA.
Got it, and there’s an important detail: you’re running agents via Linear delegation (issue → agent), not calling the cloud-agent API directly. That means the final payload from the API response never reaches your pipeline, so the workaround from my post above won’t work for you. I’ve noted this separately.
To avoid mixing two topics in one thread (this one started as local CLI hooks), it makes sense to move the cloud observability case into a separate thread so it’s easier to track separately from the CLI side. If you create one, drop the link here and I’ll attach it. Once there’s movement on cloud lifecycle hooks, I’ll follow up.
.