Automation subagents lost all inherited MCP tools since Jul 31 — child run spawns without parent agent state

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

Same failure mode as the (now closed) topic 156200 — “In cursor automation, the subagents don’t inherit the MCP servers” — opening a new report with the Background Agent IDs staff asked for there, plus a clean regression window.

Setup: a PagerDuty-triggered automation (cloud agents) delegates to custom subagents defined in .cursor/agents/*.md (pinned models — grok-4.5 / claude-opus-5 — and readonly: false). The parent automation has Datadog, New Relic, PagerDuty and Slack MCP servers configured, and subagents inherited all of them correctly for ~10 days.

Regression window: last healthy run 2026-07-31T16:27Z (subagents used MCP tools normally); first failing run 2026-07-31T23:25Z. Every run since fails the same way (5+ runs). Nothing changed on our side: the subagent files were last touched on Jul 30 (verified via git history, with 5 healthy runs after that), and the automation config was not edited in that window.

Symptom: each custom subagent now spawns as its own cloud agent run (own bcId, branchName: null) on the same VM/workspace as the parent. Inside the subagent run:

  • only the internal cursor-cloud MCP server is listed as active — none of the parent’s MCP servers;
  • a tool search for datadog|search_datadog returns matches: [];
  • “Cursor Cloud environment info” returns “This run’s agent state could not be loaded, so the enforced egress policy is unknown” — which looks like the root cause: the child run fails to load the parent agent state, and the MCP toolset comes from that state.

Meanwhile the parent run keeps all MCP tools working (it now re-runs the analysis inline as a fallback).

bcIds (child subagent runs, 2026-08-03 ~16:41Z):

  • bc-d20ad359-8b2f-5c8d-8fe6-d8549503f525 (“Datadog deep analysis for PD incident #100”, grok-4.5)
  • bc-9f000a84-5f8f-5171-94e1-fdda682b2b9b (New Relic analyst, grok-4.5)

Parent run: 2026-08-03 16:38–16:52 UTC, branch cursor/orquestrador-de-incidentes-pagerduty-e11b. Full parent transcript exported and available if useful.

This contradicts the documented behavior (“Subagents inherit all tools from the parent, including MCP tools from configured servers”) and what staff confirmed in the “Cursor Subagent MCP Toolset Control Request” thread in May.

Currently testing model: inherit on all subagents as a workaround (hypothesis: the separate-run spawn path only triggers when the subagent model diverges from the parent). Will report back.

Steps to Reproduce

  1. Create an automation (cloud agent) with MCP servers configured on it (e.g. Datadog + Slack).
  2. Add a custom subagent in .cursor/agents/<name>.md with a pinned model: different from the parent’s (e.g. grok-4.5) and readonly: false.
  3. Trigger the automation and have the parent delegate a task to that subagent.
  4. Inside the subagent run, list the available MCP servers/tools.

Expected: subagent inherits the parent’s MCP servers (documented behavior — and how it actually worked until 2026-07-31T16:27Z).
Actual: subagent starts as a separate cloud agent run with only cursor-cloud listed as active server, “This run’s agent state could not be loaded”, and zero MCP tools.

Expected Behavior

Custom subagents defined in .cursor/agents/*.md should inherit all MCP tools from the parent automation run, as documented (“Subagents inherit all tools from the parent, including MCP tools from configured servers”) and as it worked until 2026-07-31T16:27Z. The child run should load the parent agent state instead of starting with an empty MCP toolset.

Operating System

Linux

Version Information

Cloud Agent runs (server-side, automations) — no local version involved in the failure path. Local IDE for reference: Cursor 3.14.7, Linux. Affected cloud agent runs from 2026-08-03 (bcIds in the description).

For AI issues: which model did you use?

Parent automation: Sonnet 5; subagents pinned via frontmatter: grok-4.5 / claude-opus-5

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

Hi @Matheus_Coimbra_Mora Thank you for the post! This is an issue we’re tracking: subagents spawned from an automation run were starting without the parent’s MCP servers attached, which is why only cursor-cloud showed up as active and why the environment lookup came back empty.

The change behind it was reverted at around 17:50 UTC today (Aug 3). Automation runs started after that point should have full MCP inheritance again. Anything already in flight before then will keep the previous behavior until it finishes, so the cleanest check is to trigger a fresh run.

One note on your workaround: model: inherit shouldn’t be necessary. This wasn’t tied to the model pinned in your subagent frontmatter, so you can leave your grok-4.5 and claude-opus-5 pins as they are. I’ll repost here once the fix is confirmed and closed.

9

Hi @Matheus_Coimbra_Mora, this should be fixed now. Can you try again and let us know how it goes?