Describe the Bug
Subagent delegation is broken because the agent session does not have the Task tool available.
This happens even though custom subagent files exist and are valid under .cursor/agents/. or even under user agents.
Observed behavior:
Agent replies with variants of:
“I don’t have any available Task tools on my side”
“Tool not found: Task”
Affects all custom subagents.
Reproduces for multiple users/coworkers, not just one machine.
Reproduces after restarting Cursor and trying different models.
*For a few custom subagents we manage to run using sonnet 4.5 without thinking, but this seems to be intermittent, at the beginning of the session it says it found the tool, but when trying to use the tool it fails. Then at the end it does not work.
Steps to Reproduce
Create/confirm subagent files in project at .cursor/agents/ (example: hls-translator.md) with valid metadata.
Open a new Agent chat in Cursor IDE.
Ask agent to delegate to a subagent (e.g., run /hls-translation flow that requires subagent delegation).
Observe failure message indicating missing Task tool.
Repeat with:
Auto model
Composer model
One or more specific models (e.g., Sonnet/GPT/Opus)
Repeat on another user machine/account (same result).
Expected Behavior
Agent should have Task tool available in IDE session and successfully delegate to configured subagents.
Operating System
Windows 10/11
Version Information
Version Information
Version: 2.6.22 (user setup)
VSCode Version: 1.105.1
Commit: c6285feaba0ad62603f7c22e72f0a170dc8415a0
Date: 2026-03-27T15:59:31.561Z
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.22631
For AI issues: which model did you use?
auto, composer, gpt 5.4, opus 4.6, opus 4.5, sonnet 4.6, sonnet 4.5 (with and without thinking)
For AI issues: add Request ID with privacy disabled
Request ID: 4288a45b-5cdf-454c-8d84-230beaad667e
Request ID: 8f0db433-8fd1-4d73-852f-6f34f64f1070
Request ID: e389e000-ad99-447a-8d02-7c714ed22b0a
Request ID(other person): 8b4619d5-b18a-458e-be74-8d87d2aae2cf
Request ID(other person): be3c3e59-a793-4676-a97a-8e0320e0c20e
Additional Information
Confirmed subagent files exist in project:
.cursor/agents/hls-translator.md
Problem is not limited to custom subagents; built-in subagents also fail.
Reproducible across coworkers and machines.
Restarting Cursor and switching models did not resolve.
Does this stop you from using Cursor
Sometimes - I can sometimes use Cursor
Hi @Cesar_Pereira,
Thank you for the detailed report and the multiple Request IDs. I’ve confirmed on our end that the Task tool is not being provisioned in your agent sessions – this is a server-side issue, not anything related to your subagent file setup or model selection.
We’re aware of this affecting some users and are investigating. A similar report from another enterprise user is tracked in this thread as well.
A couple of things that would help us narrow down the root cause:
-
Has this ever worked for you on this version (2.6.22), or has subagent delegation been broken since you started using it?
-
Is your team on a request-based or usage-based (token-based) plan? You can check at cursor.com/dashboard under usage – if it shows “Requests” as the unit, it’s request-based; if it shows a dollar amount, it’s usage-based.
Hi @mohitjain
Thank you for the prompt reply.
Follows my answers:
- I’m not sure if the version was different previouslly, what we know is that we started facing it last week. The oldest request ID is 43985136-35db-43e4-b816-a70580ba71cc
- It seems to be request based, but there is also a budget in dollar after exceeding the total requests available.
Hi @mohitjain
Do you have any ETA for that?
We use subgents for majority of our features, which we use everyday to support our daily workflow.
If this is going to persist for a long time we would need to replace the subagents.
Additional update:
- I tried to rollback to version 2.5 and I faced the same issue.
- I just tested with the recent released version 3.0.4 and I’m still having the same issue.
Using specific model and v3: 531b9f45-e443-4940-af85-25cef2307944
Using auto and v3: cd4c0814-7eb5-43fa-b8ec-307b75efb42f
Thank you for the additional testing on v2.5 and v3.0.4, and for the new Request IDs. I’ve confirmed that the Task tool is still not being provisioned on your latest attempts — this is a server-side issue affecting your account, not something that will be fixed by changing client versions.
Regarding ETA: Unfortunately, I don’t have a specific timeline to share. This is affecting several enterprise users, and our team is actively investigating. I understand this is blocking your daily workflow, and I’ll escalate internally to get more visibility on prioritization.
One thing to check in the meantime:
If your team is on a request-based plan. For request-based enterprise users, subagents require either:
Could you confirm:
-
Is Max mode available and enabled for your users?
-
Does your team have any model restrictions configured in the admin dashboard (e.g., Composer blocked)?
If Composer is blocked at the team level, that would explain why the Task tool isn’t appearing — subagents for request-based users are currently routed through Composer. Unblocking Composer (if that’s possible for your team) could be a workaround while we work on a proper fix.
I’ll post an update here as soon as I have more information from the team.
Hi @mohitjain
thank you for the feedback.
Follows my answers:
-
MAX mode is blocked by admin, but it was always blocked, even before when subagents were working properly.
-
Composer 1.5 is available, as always, but composer 2 and 2-fast are blocked by admin due to latest public issues with Kimi vs composer 2.
Anyway, yesterday we started facing success scenarios again, today it seems it is working good also. With both specific models and Auto usage.
We are going to continue testing, but it seems it is ok now.
Thank you for the detailed answers and the positive update.
To clarify: Max mode being blocked would not have been the cause here, so that checks out with your observation that it was always blocked. The issue was on our side — a server-side fix was deployed that corrected how model restrictions interact with subagent routing. Since your team has Composer 1.5 available, subagents should now route through it correctly.
Please do continue testing, and if you see the issue return, reply here with a Request ID and I’ll investigate it.
Glad things are back on track.