Cloud Agents: `subagentStart` / `subagentStop` never fire for any Task subagent (foreground, background, explore), while tool and shell hooks fire normally

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

On Cursor-managed Cloud Agents, subagentStart and subagentStop project hooks never run when the agent spawns a subagent with the Task tool. The docs (Hooks → Cloud agent support) list both as supported in cloud agents.

Other hooks from the same .cursor/hooks.json run normally on the same VM, in the same chat: beforeShellExecution, afterShellExecution, preToolUse, postToolUse, beforeReadFile, and stop.

We ran two independent tests on fresh cloud agents with a passive probe on all 18 documented agent hook events. Result:

Spawn subagentStart subagentStop Parent preToolUse for the Task call
Foreground, generalPurpose never never never
Foreground, explore never never never
Background, generalPurpose never never never

Other observations from the same test:

  • The children’s own tool hooks do fire. Each child logs preToolUse / beforeShellExecution / postToolUse under its own conversation_id (a bc-… id that differs from the parent’s).
  • A child fires no stop and no beforeSubmitPrompt. stop fired only for the parent turn.
  • The hook payload of a child has no field that links it to the parent (no parent_conversation_id, no subagent_id, no task text). transcript_path is null for the parent and for every child.
  • Inside a child, the agent metadata socket (/v1/meta-data/agent/id) returns the parent’s agent id, not the child’s.
  • The spawn tool call shows agentId: bc-… and machine: sameMachine. So on cloud a subagent seems to be a separate child agent on the same VM. This may be why the subagent lifecycle hooks are skipped (possibly since “Subagents on their own machines”, Aug 19).

As a result, a cloud agent’s hooks cannot observe or gate subagents. Any workflow that records subagent start/stop or blocks certain subagent types works locally but silently does nothing in cloud agents.

Steps to Reproduce

  1. Commit this .cursor/hooks.json (the script must be committed and executable):
{
  "version": 1,
  "hooks": {
    "subagentStart":        [{ "command": ".cursor/hooks/trace.sh subagentStart" }],
    "subagentStop":         [{ "command": ".cursor/hooks/trace.sh subagentStop" }],
    "preToolUse":           [{ "command": ".cursor/hooks/trace.sh preToolUse" }],
    "postToolUse":          [{ "command": ".cursor/hooks/trace.sh postToolUse" }],
    "beforeShellExecution": [{ "command": ".cursor/hooks/trace.sh beforeShellExecution" }],
    "stop":                 [{ "command": ".cursor/hooks/trace.sh stop" }]
  }
}
  1. Commit .cursor/hooks/trace.sh (mode 755):
#!/usr/bin/env bash
# Passive probe: saves the hook payload, prints nothing, always exits 0.
mkdir -p /tmp/hooktrace
cat > "/tmp/hooktrace/$(date +%s%N)-$1.json"
exit 0
  1. Start a new Cloud Agent on that branch with this prompt:
1. Run: echo control
2. Use the Task tool to spawn a foreground generalPurpose subagent: "Run: echo child-A"
3. Use the Task tool to spawn a foreground explore subagent: "Read .cursor/hooks.json and reply with the number of keys under hooks."
4. Use the Task tool to spawn a background subagent: "Reply with the word OK." Wait until it has finished.
5. Run: ls /tmp/hooktrace
  1. Look at the file list from step 5.

Expected Behavior

One subagentStart and one subagentStop for each of the three subagents, with the documented payload (subagent_id, subagent_type, task, status, …).

Actual Behavior

There are files for beforeShellExecution, preToolUse, postToolUse, stop, and the children’s own tool hooks. There are zero subagentStart and zero subagentStop files. There is also no preToolUse for the Task call itself.

Operating System

MacOS

Version Information

Version: 3.22.12 (Universal)
VS Code Extension API: 1.128.0
Commit: 3a92974361033b2051526321308c2740fe5912c0
Date: 2026-09-26T04:55:12.125Z
Layout: Agent Window
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Darwin arm64 25.6.0
Cloud Agent (Cursor-managed VM): hook payloads report "cursor_version": "1.0.0" (looks like a placeholder).

For AI issues: which model did you use?

Not model-specific. Seen with claude-opus-5-5-high (parent agent and generalPurpose subagents) and composer-2.5 (explore subagent).

For AI issues: add Request ID with privacy disabled

  • Test 2 (all 18 hooks traced) — parent: bc-00c63660-f7d2-4a1b-8315-36ea8bf7dd26
    • children: bc-0df15be6-fc6c-5b61-8549-d4f70d8c0442 (generalPurpose, foreground)
      • bc-877fc796-d4f7-529a-bd0f-2f6dab7e3703 (explore, foreground)
      • bc-4c5a87de-ded7-520f-a07a-8866cdcc1306 (generalPurpose, background)
  • Test 1 — parent: bc-59599119-0dda-4b45-b663-cb314004c755
    • child: bc-269f5187-99e6-551c-8469-cbe40cae28a0 (generalPurpose, foreground)

Request ID: d2ef66e2-4b95-43c3-bf16-0857b5540431

Does this stop you from using Cursor

Yes - Cursor is unusable

Hey @EL_JSQ,
This isn’t caused by your hooks.json, and it’s an issue we’re tracking. It looks like subagents started in a cloud agent’s first turn are the ones missing these hooks, so could you try this?

  1. Start a new Cloud Agent on the same branch with only Run: echo warmup as the first message.

  2. Once that turn finishes, send your 5-step subagent prompt as the second message.

  3. Check ls /tmp/hooktrace.

If subagentStart / subagentStop show up, starting with a short first message should work around it for now. Either way, please reply with the result and the new agent’s bc- ID. I’ll post here when there’s an update.

Thanks @mohitjain, that worked.

Agent: bc-c126a9b2-b664-4278-a50f-42ca10c20c2f

  • First message: “Run: echo warmup”
  • Second message: started an explore and a generalPurpose subagent with the built-in Task tool

ls /tmp/hooktrace:
beforeShellExecution.jsonl
subagentStart.jsonl
subagentStop.jsonl

subagentStart fired for both subagents (explore and generalPurpose). subagentStop fired for generalPurpose. Our stop matchers don’t include explore, so that one was not expected.

So the bug only affects subagents started in a Cloud Agent’s first turn. We’ll use a short first message until the fix ships. Please post here when it does.