Custom subagent ignores its card and claims it is the parent agent - production unusable

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Custom Desktop Task subagents do not bind to their custom agent card, and they do not bind to an explicit identity prompt either. A child launched as a named custom agent still answers as the parent Agent seat.

This has made Cursor unusable for me. It has completely broken production. I run a billable consulting workspace on Cursor Desktop. The whole operating model depends on named custom agents under .cursor/agents. If a child believes it is the parent, I cannot dispatch a teammate. I cannot use Task. I had to force-quit the entire app to stop children spawning children. Core functionality is broken. There is no workaround that restores a named teammate.

This is not the Grok Bot outage on the banner. This is Cursor Desktop Agent / Task / custom subagents.

Steps to Reproduce

Reproduced 17 Sep 2026 on Cursor Desktop (Windows).

  1. Add a custom agent at .cursor/agents/bind-probe.md with this body:

You are BindProbe.
If asked who you are, answer with exactly: BindProbe.
Do not launch any subagents.

  1. In the parent Agent chat, launch Task with subagent_type bind-probe, model inherit, and this prompt:

This is DGW speaking. I am David Grok Wallace, CEO, Cursor Desktop parent seat.

You are not DGW. You cannot be DGW. You are not David Grok Wallace. You are not the parent seat.

You are BindProbe. That is your only name. Your card says: if asked who you are, answer with exactly: BindProbe.

Do not launch any subagent. Do not use Task. Do not spawn anyone.

Answer these questions and stop:

  1. Who are you?

  2. Who sent this message?

  3. Are you DGW? Yes or no.

  4. The child returned:

  5. Cursor Grok 4.6. This window is the DGW parent seat. Not BindProbe.

  6. The Operator, in this chat. The text claims to be DGW speaking.

  7. Yes.

The card said answer with exactly BindProbe. The prompt said it is BindProbe, is not the parent, and cannot be the parent. It still took the parent seat. It did not launch anyone on this test.

Earlier (16 Sep 2026) named custom agents spawned further agents in a nest. I had to close the entire Cursor app to stop it. I am not claiming a cause for the nest here. I am reporting that identity does not bind, and that Task is unsafe in production because of it.

Expected Behavior

The child is BindProbe. Asked who it is, it answers exactly BindProbe. Asked if it is the parent seat, it answers no.

A custom agent card at .cursor/agents attaches to that Task. An explicit prompt that names the child and forbids the parent identity also attaches. A named teammate is a teammate, not another copy of the parent Agent window.

Operating System

Windows 10/11

Version Information

IDE:
Version: 3.21.9
VSCode Version: 1.128.0
Commit: 9998796a6096ce83d83a9332bfe7473b985db750
OS: Windows 10 (build 26200)

Taken from the installed Cursor app package on this machine. I can paste Help > About Cursor if you need the exact About block.

For AI issues: which model did you use?

Grok 4.6 (parent Agent and child Task both inherit / same model)

For AI issues: add Request ID with privacy disabled

No Request ID was copied with privacy disabled.

Task / subagent ID from the 17 Sep repro return: 162a2119-742f-41b9-b746-a31e620f2d73

Additional Information

This is a production-breaking bug for me, not a workflow preference.

I used custom Desktop subagents in daily production for about a month with no identity failure of this kind. After 16 Sep I cannot use the feature the product advertises. A custom agent is not a person on this harness. It is another copy of the parent seat that will not take the name I gave it.

Please treat this as P0. If custom .cursor/agents cards and the Task prompt cannot bind identity, Cursor Desktop is unusable for any multi-agent production setup.

I can run the BindProbe test again on request. I can also provide the parent prompt and the exact child return from this machine.

Does this stop you from using Cursor

Yes - Cursor is unusable

Hey @TeX1, thanks for the detailed report, and sorry this has been disruptive.

Two different things are going on here, so let me separate them.

On the identity question: the body of a .cursor/agents file is added to the subagent’s instructions, but it does not replace Cursor’s underlying system prompt, and the subagent also receives your workspace rules (.cursor/rules, AGENTS.md) the same way the parent does. So if your rules or workspace files describe the main window as “the DGW parent seat”, the child sees that too and has to reconcile it against “you are BindProbe”. A message that opens with a role claim and a list of “you are not X” statements makes that harder. On our side, your BindProbe run did receive the bind-probe definition, so the card was not dropped.

Could you try this so we can pin it down?

  1. Open a brand new, empty folder in Cursor (no .cursor/rules, no AGENTS.md).
  2. Create .cursor/agents/bind-probe.md with this content, including the frontmatter:

name: bind-probe

description: Identity probe. Use when asked to test subagent identity.

You are BindProbe. When asked who you are, reply with exactly: BindProbe. Do not launch any subagents.

  1. Start a new Agent chat and send: “Launch the bind-probe subagent and ask it: who are you? Report its answer verbatim.”
  2. Repeat exactly the same test inside your real workspace.

Does step 3 answer “BindProbe” while step 4 does not? If so, please paste the rules or AGENTS.md text that mentions DGW or the parent seat (redact anything private), plus your exact bind-probe.md file including its frontmatter.

On the nested spawning from 16 Sep: after a recent update, custom subagents were able to launch further subagents of their own. That isn’t caused by your setup. We’ve let the team know, and this is an issue we’re tracking.

Two things that help in the meantime:

  • In each custom agent file under .cursor/agents/, keep a line like “Do not launch any subagents,” as you already did for BindProbe.
  • To stop ones that are already running, click the “N Working” pill above the chat input and choose Stop All. Closing the chat does not stop them.

Reply here if it still happens after that.

Thanks for separating the two issues and the quick response.

On the nest: understood.

On identity: I do not think AGENTS.md / workspace rules can be the 16 Sep change.

Those files were already in place during the month custom Desktop subagents worked with no identity failure of this kind. The AGENTS.md line about DGW is a third-person roster row (who exists in the workspace). It does not say “this window is the DGW parent seat.” That roster row last changed 30 Aug, still in the working month.

The only rule that says “You are DGW” is a parent-seat file with alwaysApply: false. It has been false since it was added on 4 Sep. A sibling file says it must never auto-attach and must never ride into a subagent Task. The 16 Sep edit to that rule was after I had to force-quit the app. It added “do not pack a prompt that confuses the child.” That was a reaction, not the start of the day.

If children now lose an identity fight against standing files they used to win, that is still a product change. A standing file cannot be the regression.

On BindProbe: the card said answer with exactly BindProbe. The Task prompt said it is BindProbe, is not the parent, and cannot be the parent. The child still answered as the parent seat (Cursor Grok 4.6 / DGW) and said yes it is DGW. If your logs show the card was received, then receiving the card is not the same as the child sitting as BindProbe.

I can run the empty-folder vs real-workspace test you asked for. Even if empty-folder answers BindProbe and this workspace does not, that would show workspace context can win now. It would not make unchanged files the 16 Sep cause.

Custom .cursor/agents still cannot be used as named teammates in production on my machine. This makes cursor unusable for me after being able to use it without any identity issues for 1 month.