subagentStart and subagentStop hooks never fire (foreground or background), while beforeShellExecution from the same hooks.json works normally

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Since sometime between 2026-08-14T07:55Z and 2026-08-18T07:49Z, the subagentStart and subagentStop hooks stopped firing entirely — for both foreground and background Task-tool subagents — while beforeShellExecution hooks from the same .cursor/hooks.json continue to fire normally. Saving hooks.json (auto-reload) does not help.

Evidence from our instrumented hook script (it logs every invocation with timestamps):

  • Last subagent-stop: 2026-08-14T07:55:39Z; subagent hooks fired repeatedly on 2026-08-13/14 with full payloads (subagent_id, subagent_type, transcript_path, parent_conversation_id).
  • 2026-08-18: 76 beforeShellExecution invocations, but 0 subagentStart and 0 subagentStop across 4 independent Task launches (2 background, 2 foreground).
  • .cursor/hooks.json unchanged since 2026-08-13 15:16 local; hook script unchanged since 2026-08-13 17:26 local; no hooks-related settings in settings.json.

This is worse than the already-confirmed background-only subagentStop bug (linked in Additional Information): even foreground subagentStart does not fire.

Steps to Reproduce

  1. Register .cursor/hooks.json with subagentStart, subagentStop, and beforeShellExecution hooks pointing at a script that appends every invocation to a log file:
{
  "version": 1,
  "hooks": {
    "subagentStart": [{ "command": "node .cursor/hooks/log.mjs subagent-start", "timeout": 10, "failClosed": true }],
    "subagentStop": [{ "command": "node .cursor/hooks/log.mjs subagent-stop", "timeout": 10, "failClosed": true }],
    "beforeShellExecution": [{ "command": "node .cursor/hooks/log.mjs before-shell", "timeout": 10, "failClosed": true }]
  }
}
  1. Launch any Task subagent (foreground or background) and let it complete.
  2. Run any shell command in the agent.
  3. Observe: only the beforeShellExecution invocation is logged. No subagentStart/subagentStop invocations occur.

Expected Behavior

subagentStart should fire when a Task subagent is spawned, and subagentStop should fire when it completes — at minimum for foreground subagents (the documented background-only subagentStop gap is tracked separately; see Additional Information). Any workflow that captures a subagent’s typed result at subagentStop is entirely broken, including the foreground path that should work.

Operating System

MacOS

Version Information

Cursor 3.11.19 (stable)
Commit: bf249e6efb5b097f23d7e21d7283429f0760b74a
VSCode: 1.125.0

For AI issues: which model did you use?

N/A — not an AI-model issue (IDE hooks platform)

Additional Information

Related confirmed issues in the same area:

Additional notes:

  • The newest cursor.hooks.*.log under ~/Library/Application Support/Cursor/logs/ is from 2026-07-15 and contains only initialization lines; no hooks-service log exists for the currently affected window, which may itself be a symptom.
  • I can attach full instrumented hook-event log excerpts on request.

Does this stop you from using Cursor

No - Cursor works, but with this issue

3

Update: restarting Cursor restored the hooks (with one remaining caveat)

After fully restarting Cursor, the same test now produces both subagentStart and subagentStop events for foreground subagents, with normal payloads.

For background subagents, subagentStart fires but subagentStop still never fires — this matches the already-tracked bug in topic 166681, so no separate report needed for that part.

What remains unexplained is the pre-restart state: neither event fired at all (foreground or background) while beforeShellExecution from the same hooks.json kept working, and saving hooks.json did not restore them. Only the full app restart recovered them. If hook registration/emission can silently degrade over time, it may be worth adding diagnostics — happy to provide the instrumented hook-event logs if useful.

6

Hey, thanks for the detailed update. Good to hear a full restart brought back the foreground subagentStart and subagentStop.

About background subagentStop, that’s a known issue we’re already tracking, same as topic 166681, so you’re all set and no separate report is needed.

What we still need to figure out is the transient state before the restart, when all subagent hooks were silent, but beforeShellExecution from the same hooks.json kept working. To dig deeper, it’d help if you could share:

  1. The Request ID from the session where the subagent started but the hook didn’t fire Chat menu in the top right > Copy Request ID. If the email you’re currently using in Cursor is different from the one linked to your forum account, please share that too, otherwise we can’t find the session in logs.
  2. The contents of Output > Hooks channel from that time period.
  3. Those instrumented hook-event logs you mentioned, please post them here.

Also, you’re on 3.11.19, which is about a month old, and both hook code paths have changed since then. Please update to the current stable and check if the transient issue still reproduces. It’s very possible it won’t show up on the latest version.

Let me know how it goes.

8

Thanks for the follow-up. Agreed that background subagentStop belongs with the already-tracked issue (topic 166681). Below is what I have for the pre-restart transient, when all subagent hooks were silent but beforeShellExecution from the same hooks.json kept working.

  1. Request ID / session identifiers

Copied Request ID from this chat (Copy Request ID): 29095b33-91dc-4003-b28a-a943d53b481c

That copy is from the current turn in the same conversation. The failing Task launches were earlier in this conversation, before the restart. Identifiers from our instrumented hook log:

  • conversation_id: da0e625f-f367-4d80-bee8-4def15868774
  • silent-period generation_ids in that conversation (beforeShellExecution fired; no subagentStart/subagentStop):
    • 699cae6a-df47-40b6-a648-54225bc085d1 (2026-08-18T13:33Z)
    • f65526ee-949a-4228-af26-b099333d360b (2026-08-18T13:46Z)
    • 34adbed1-7648-4f4c-b058-985b67b35764 (2026-08-18T14:23Z)

Cursor account email: [email protected]

  1. Output > Hooks from that window

I did not capture the Output > Hooks channel while it was failing. On disk, the newest cursor.hooks.*.log under ~/Library/Application Support/Cursor/logs/ is from 2026-07-15 and only has initialization lines. There is no hooks-service log covering 2026-08-14 through 2026-08-18. Happy to capture Output > Hooks on a later occurrence if the transient comes back.

  1. Instrumented hook-event log (sanitized)

Our hook script appends every invocation. Same hooks.json / same script the whole time.

Last successful subagentStop before the silence:

  • 2026-08-14T07:55:39.854Z hook=subagent-stop conversation_id=ac494511-8ad8-4b3d-bf98-0d0797989a91 status=completed

Then a gap. Next events are 2026-08-18, and until the restart they are before-shell only.

2026-08-18 before restart:

  • 76+ beforeShellExecution
  • 0 subagentStart
  • 0 subagentStop
  • 4 Task launches in that window (2 foreground, 2 background) completed with no subagent hook lines at all

Example silent-period before-shell (this conversation, about 30 minutes before restart):
{“ts”:“2026-08-18T13:33:24.299Z”,“hook”:“before-shell”,“conversation_id”:“da0e625f-f367-4d80-bee8-4def15868774”,“generation_id”:“699cae6a-df47-40b6-a648-54225bc085d1”,“hook_event_name”:“beforeShellExecution”}

After a full Cursor restart, same conversation, same hooks.json, first test:
{“ts”:“2026-08-18T14:52:43.742Z”,“hook”:“subagent-start”,“conversation_id”:“da0e625f-f367-4d80-bee8-4def15868774”,“subagent_id”:“Task_0_845bbf74-8e792”,“subagent_type”:“explore”,“hook_event_name”:“subagentStart”,“permission”:“allow”}
{“ts”:“2026-08-18T14:52:52.804Z”,“hook”:“subagent-stop”,“conversation_id”:“da0e625f-f367-4d80-bee8-4def15868774”,“subagent_id”:“Task_0_845bbf74-8e792”,“subagent_type”:“explore”,“hook_event_name”:“subagentStop”,“status”:“completed”}

Saving hooks.json did not restore the silent state. Only the full app restart did. I have not been able to reproduce the total subagent-hook silence again since that restart (still seeing foreground start/stop as of 2026-08-19). I do not have a reliable repro for the transient itself.

Version / update

Still on Cursor 3.11.19 (stable), commit bf249e6efb5b097f23d7e21d7283429f0760b74a, VSCode 1.125.0 — the version that hit the transient. I will update to current stable next and report back whether the transient returns. I cannot force the silent state on demand, so that follow-up will be “has it recurred after the update,” not a guaranteed repro.

Happy to attach a longer sanitized excerpt if useful.

9

Hey, thanks for such a detailed dump. The Request ID, conversation and generation IDs, and especially the active account are exactly what we need to check the silent-period sessions on our side. The forum account in the logs was empty, so we didn’t have anything to latch onto before.

On the background subagentStop, we’re aligned. This is already tracked under topic 166681, so there’s nothing extra you need to do.

On the transient issue where all subagent hooks go quiet but beforeShellExecution from the same hooks.json still works, and it only gets fixed by a full restart. Since it’s not reproducible on demand, the most useful next step is updating to the current stable version. You’re still on 3.11.19 from mid-July, and both hook paths have changed a lot since then, so it’s possible the issue just won’t show up on a newer build.

If the issue comes back after the update, it’d be ideal to capture the Output > Hooks content at that moment, what we didn’t manage to grab last time, plus the generation_id from the session where the Task subagent ran without hooks. With that, we can match the client and server side at the same time.

Let me know how the update goes and whether the transient issue shows up again.

10

Seventy-six beforeShellExecution events with zero subagent lifecycle events is a solid negative control. The dangerous part is that the hook system looks healthy while dropping the exact ownership events a workflow may rely on. I’d add a startup probe that fails closed if start/stop receipts are missing, plus monotonic event IDs so recovery can distinguish “no subagents” from a gap in the event stream.

11

Hey, thanks for the thought, that’s a solid observation. 76 beforeShellExecution events with zero lifecycle events is a really good negative control: the system looks healthy, but it’s dropping exactly the events a workflow might rely on.

The idea of a fail-closed startup probe when start or stop receipts are missing, and using monotonic event IDs to tell “there were no subagents” apart from a gap in the stream, sounds like a good direction for hook observability.

On this thread: the transient state where all subagent hooks go quiet while beforeShellExecution from the same hooks.json keeps working isn’t reproducible on-demand yet, so we’re actively looking at diagnostics like yours. Separately, the background subagentStop is an issue we’re already tracking: `subagentStop` never fires for background subagents; documented `summary` / `modified_files` / `agent_transcript_path` missing or null

If you have an instrumented case where you can catch this, I’d love the details: Request ID, generation_id, and the contents of Output > Hooks at the time of the failure.

12

We use Cursor through the SDK in CodeFlowMu and haven’t observed the
behavior reported here. My comment was about how to detect missing
lifecycle events, rather than a reproduction from our setup.

13

Hey, thanks for clarifying. I understand your comment was about an approach to detecting missing lifecycle events, not a repro from your SDK setup. It’s a good direction: a fail-closed probe on startup if start or stop receipts are missing, plus monotonic event IDs to tell “there were no subagents” apart from a gap in the stream. That seems like solid logic for observability hooks. I shared it with the team as feedback.

On this thread, the status is unchanged: the transient case where all subagent hooks go silent, but beforeShellExecution from the same hooks.json keeps working, isn’t reproducible on demand right now. So we’re digging into diagnostics like what @kiyoungchoi shared. If anyone manages to catch an instrumented case, the Request ID, generation_id, and the contents of Output > Hooks at the time of the failure are what will help us most.

Background subagentStop is being tracked separately (topic 166681). I’ll post here if there’s an update.