Newish subagent feature does not always save files/perist changes that the sub agent makes

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Newish subagent feature does not always save files/perist changes that the sub agent makes. Opus made about 4 subagents, three for frontend tasks/research, and one for backend tasks. The frontend agent returned, and the main agent saw the changes. The backend agent returned, and the agent could see that there were changes. I pressed apply and it had only applied front-end changes that were made.

In the actual subagent output, you can see where it made changes too, which Opus could use to just reapply them again with perfect accuracy so it wasn’t a big deal. Opus is also not sure where to find the original files for the subagent, i.e. where the subagents worktree is. It checked its own worktree (in ~/.cursor/worktrees/) and came to the conclusion that the files were not persisted to disk, but I think that’s only becuase it doesn’t know where subagents make changes (neither do I).

Steps to Reproduce

I have no clue how to reproduce this, but it tends to happen when multiple sub agents are making changes.

Expected Behavior

For all the changes to be persisted

Operating System

Windows 10/11

Version Information

Version: 2.5.25 (system setup)
VSCode Version: 1.105.1
Commit: 7150844152b426ed50d2b68dd6b33b5c5beb73c0
Date: 2026-02-24T07:17:49.417Z
Build Type: Stable
Release Track: Default
Electron: 39.4.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

opus max

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

3

Hey, thanks for the report. This looks like a known race condition where multiple sub-agents write files at the same time, and some changes get lost during apply. It happens more often when the backend and frontend agents finish around the same time.

The team is aware of this issue. Your report helps make it more visible, especially the detail about which changes “survived” and which got dropped.

A couple things that would help us investigate:

  1. Request ID: You can copy it from the chat menu in the top right, then select Copy Request ID. If that session is still open, that’s ideal.
  2. You’re on version 2.5.25, which is a bit outdated. Can you update to the latest stable and see if it still happens?

As a workaround, if a sub-agent’s changes disappear after apply, you can ask the main agent to re-apply them from the sub-agent output, like you did. Running fewer sub-agents in parallel can also reduce the chance of hitting this.

Let me know if it happens again on the latest version.