This issue has been around for 10 days. Why hasn’t it been fixed promptly
Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
I have observed THREE distinct symptoms, all surfacing as the same
“Starting up” card. Please treat each as a separate sub-bug under
the same root cause if needed.
Mode A - “Stuck Starting up, no actual work happens”:
Card stays on “Starting up” forever. No backend activity. Eventually
auto-cancelled at ~256 sec with the misleading “interrupted by the
user” message. Filesystem evidence: no new entries in
agent-transcripts/, terminals/, or any target file the prompt
was supposed to write.
Mode B - “Stuck Starting up, but the sub-agent IS doing real work”:
Card stays on “Starting up” indefinitely, BUT the sub-agent is
actually running successfully in the background. Filesystem
evidence shows real activity: new agent-transcripts// files
appear, new terminals/ entries are created, target files are
edited, and progress continues for many minutes. The UI never
transitions the card out of “Starting up” - so the user has no
visibility into progress, no token / cost stream, no live tool
call list, and no way to pause or interrupt cleanly. This is
arguably the worst variant: it silently succeeds without any way
for the user to confirm.
Mode C - “Card just hangs”:
Variant of A or B where the card never reaches a terminal state
at all (no failure, no completion). User has to manually dismiss
it and trust nothing was lost.
Steps to Reproduce
It is occuring in all long running workflows.
Expected Behavior
I should be able to see the progress of sub agents, also interact with their terminal commands or any actions which required approval.
Operating System
MacOS
Version Information
Version: 3.1.17 (Universal)
VSCode Version: 1.105.1
Commit: fce1e9ab7844f9ea35793da01e634aa7e50bce90
Date: 2026-04-19T19:33:58.189Z
Layout: editor
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: Darwin arm64 25.4.0
For AI issues: which model did you use?
OPUS : 4.7
Does this stop you from using Cursor
Yes - Cursor is unusable
Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
In the past few versions (starting a week or two ago), when agent/plan chat decides on its own to use subagents for investigations, the callouts stay in “New subagent Starting up” forever. Even after they have obviously returned results (and “Starting up” still has that pulsating text effect as well).
And with this, no way to click into them to view progress/results of subagent investigation, or even the topic of each one.
Steps to Reproduce
Do that will trigger an organic submodule investigation (I dont ask for it, Cursor just decides to do it).
Expected Behavior
Subagent modules update to show the title, allow me to click on them to open new tab with progress/results of investigation, and stop “pulsating” when done, show status, etc.
Screenshots / Screen Recordings
Operating System
MacOS
Version Information
Version: 3.1.17
VSCode Version: 1.105.1
Commit: fce1e9ab7844f9ea35793da01e634aa7e50bce90
Date: 2026-04-19T19:33:58.189Z
Layout: editor
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: Darwin arm64 25.4.0
But like I said, has been like this for the bast few maintenance releases.
For AI issues: which model did you use?
Opus 4.6 thinking
Does this stop you from using Cursor
No - Cursor works, but with this issue
prompt not new subagent
+1 confirming this on Cursor 3.1.17 and 3.0.13, with a root-cause trace pinned to specific file/line locations in the renderer bundle. Multiple engineers on our enterprise tenant (Privacy Mode on, cloud/background agents disabled by admin policy) reproduce this 100% of the time. Downgrade to 3.0.13 with a fresh state.vscdb did not help.
Observed behaviour (matches @yaakov_fg and the other linked threads)
- Subagent tile renders “New subagent ‚Äî Starting up” with the pulsing shimmer, forever.
- The subagent actually runs in the background. Two independent confirmations:
- When the subagent needs no user approvals, it completes and the main agent receives its output and continues normally ‚Äî despite the tile still visibly pulsing “Starting up”. So the execution channel works; only the UI rendering channel is broken.
main.logshowsagent-loopwakelocks being acquired/released during the hang.
- When the subagent hits a tool call that requires user confirmation (the in-tile “Run” button), the workflow deadlocks. The approval button lives inside the tile, the tile never renders its body, so there is no way for the user to approve and the main agent waits forever. This is the worst case: it silently wastes a full agent run.
Root cause (pinned to bundle lines)
Static RE of the beautified workbench.desktop.main.js from 3.1.17, cross-checked against live DevTools logs:
1. Tile renders “Starting up” iff its composer handle signal h() is undefined.
The SolidJS title memo is at the bundled equivalent of:
// tile title memo
K = Be(() => {
const Ct = h()?.data.name; // composer handle
...
return /* subagent case */ ? (Ct || Ofl) : ...
})
// Ofl = "New subagent"
// Rendered as: <Show when={K() !== Ofl} fallback={<ANS/>}>
// where ANS = <div class="... task-title-shimmer"><span>Starting up</span></div>
2. The handle setter is only called on .then(jt => jt && setter(jt)). The .catch never fires.
Cn(() => {
const at = _();
if (at) t.getComposerHandleById(at).then(jt => {
_() === at && jt && (g(jt), ...) // gated on jt being truthy
}).catch(jt => { console.error("Failed to get subagent handle:", jt) });
})
When getComposerHandleById resolves to undefined (not rejects), g is never called. The catch is dead code in this failure mode.
3. Why it resolves to undefined: two error-swallowing try/catch blocks.
// ComposerDataHandleStorageBackend.loadFromStorage
async loadFromStorage(e, t) {
try {
const i = await this.backend.load(e, t);
if (i) { ... return this.registerComposer(i) }
this.refById.delete(e);
return
} catch (i) {
t(`[composer] getHandle: ${e} error=${i.stack}`),
this.refById.delete(e),
console.error("[composer] Error loading composer data:", i);
return // <-- returns undefined; does not rethrow
}
}
// ComposerDataHandleStorageBackend.getHandle
async getHandle(e, t) {
const i = { stack: [], error: void 0, hasError: !1 };
try {
const s = await this._resolveHandle(e, t ?? (() => {}));
return s && this._touchLruCache(e, s), s
} catch (r) {
i.error = r, i.hasError = !0
// ** no return statement; implicit undefined **
} finally { __disposeResources(i) }
}
Neither swallow surfaces an error sentinel. The failure mode is indistinguishable from “handle not yet resolved”, and the UI has no way to recover.
4. The live trigger for the failure in 3.1.17 is an MCPParams protobuf decode error on composer preload:
[composer] Error parsing toolFormerData
Error: cannot decode message aiserver.v1.MCPParams from JSON: key "serverIdentifier" is unknown
at Object.readMessage
at Rtr.fromJson
at Rtr.fromJsonString
at retrieveMessagesBatchInternal
at getInitialMessages
at loadFromStorage <-- swallowed here
at getHandle
at getComposerHandleById
at preloadComposerHandle <-- fires on onMouseEnter
The 3.1.17 binary writes bubble JSON with an MCPParams.serverIdentifier field that its own decoder rejects as unknown. Writer and reader are the same binary. On the affected machine, 227 rows in cursorDiskKV carried this field; surgically deleting those rows silenced the decode error but did not fix the hang, because subsequent subagent sessions keep writing more serverIdentifier rows.
5. The approval handler is also gated on h() — which is why the Run button is structurally unreachable.
Ge = () => {
const Qe = h();
if (!Qe) return; // early exit while handle is undefined
...
mt.setSelectedOption(vx.RUN)
}
Even if the button were somehow visible, clicking it would no-op. There’s no handle-free path for approvals.
A second failure mode that compounds on enterprise tenants (worth investigating)
On our tenant the admin blocks cloud/background agents by policy. We see this repeated every few seconds while a subagent hangs:
[background_composer] Listing background composers
[transport] Connect error in unary AI connect
ConnectError: [unauthenticated] You are not authorized to use cloud agents in this team.
at listBackgroundComposers
at refreshBackgroundComposersInner
On our tenant, no composerData:* rows are written to state.vscdb for stuck subagents during the hang. A colleague on a tenant with cloud agents enabled does see such rows. This suggests subagent state reconciliation may share code paths with listBackgroundComposers, which is rejected 401 on our tenant. If true, that coupling would explain why the tile gets stuck even independently of the decode bug, because the composer is never registered in the renderer in the first place.
This is a hypothesis, not a confirmed finding — flagging it so Cursor can check.
What would fix this (minimal, low-risk)
- Stop swallowing errors in
loadFromStorageandgetHandle. Return a tagged error sentinel ({ __loadFailed: true, error }) or rethrow. The UI needs to be able to tell “failed to load” apart from “still loading”. - Add an error state to the tile title memo. Right now
Konly has loading-or-loaded, so any non-success collapses to the “Starting up” shimmer. A visible error + Retry / Open Logs / Dismiss would make this class of bug self-clearing. - Fix the
MCPParams.serverIdentifierschema mismatch. Writer and reader are the same binary. Either add the field to the decoded schema, configureignoreUnknownFields, or stop emitting it. - Ungate approvals from handle loading. Provide a handle-free approval path (e.g. via
toolCallHumanReviewService.getTerminalReviewModelForBubble(composerId, bubbleId)) so the Run button is reachable even if the tile is broken. - Handle the cloud-agents 401 gracefully. Detect it once, mark the feature unavailable for the session, stop retrying. And — critically — verify that local subagent state reconciliation does not depend on a successful
listBackgroundComposersround-trip.
None of the above requires a new feature; (1), (2), (4) are ~10-line renderer changes each.
Reproducibility
100% on our tenant, across cold restarts, fresh state.vscdb, and with/without MCP plugins. Affects both 3.1.17 and 3.0.13. The forum threads below suggest it also affects tenants without cloud-agents gating, so the decode-error path is likely sufficient on its own:
- Not able to open subagent execution window on IDE
- Spawning Subagents do nothing in some circumstanses
2 Likes
1 Like
I still see this behavior in 3.2.11.
Our privacy settings are controlled by the organization (team admin), I’m on an enterprise plan.
Stuck on Starting subagent during planning phase.
Hey, quick update on this thread.
The ticket for this issue is marked as Done on our side. This was about the subagent card getting stuck on Starting up even though the subagent is actually running in the background. Big thanks to @vladbond and @Dot_Hub, your detailed analysis of the persistence write and the swallowed errors in loadFromStorage and getHandle really helped the team narrow down the root cause.
Request for everyone in this thread:
- Update to version 3.2.11+ via Help > Check for Updates.
- Reproduce your subagent workflow and reply here with whether the Starting up stuck state is gone or you still see it.
- If you still see it, please share your version via Help > About and the Request ID if Privacy Mode allows.
Hi team — quick update from my side.
I updated Cursor and the original “Starting up” issue looks improved: subagents no longer get stuck there. They now show as Completed, and I also see an Allow button for subagent internal run command options.
However, I still have a blocker: when I click the subagent tile, it opens “Loading Chat” and stays stuck forever, so I can’t access the subagent chat at all.
Version: 3.2.11
VSCode Version: 1.105.1
Commit: e9ee1339915a927dfb2df4a836dd9c8337e17cc0
Date: 2026-04-24T14:36:47.933Z
Layout: editor
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: Darwin arm64 24.6.0
Request ID: eff0ad7c-f5fe-4565-aa7d-f318268b7ed5
Thank you!
1 Like
@Dot_Hub - thanks for the update, glad the core fix worked. What you’re describing now (the tile opens in “Loading Chat” and never finishes loading) is a different symptom. So it doesn’t get lost in this thread, please open a separate bug report in Bug Reports Bug Reports - Cursor - Community Forum and include:
- version (already have: 3.2.11)
- Request ID
eff0ad7c-f5fe-4565-aa7d-f318268b7ed5 - a screenshot of the stuck “Loading Chat”
- snippets from
main.logwith[composer]orloadFromStorageerrors if you can find them~/Library/Application Support/Cursor/logs/
Drop the link to the new thread here once you’ve created it and I’ll take a look.
@BrunoChevalier - to figure out if this is the same issue or a different bug:
- After the subagent gets stuck on “Starting subagent”, does the parent agent eventually keep going and get a result, or does the conversation actually freeze (files don’t change, tokens aren’t being used)?
- If your org’s privacy policy allows it, share the Request ID from an affected session: Settings > General > temporarily turn off Privacy Mode, repro, copy the ID.
- A screenshot of the stuck tile.
If the parent still finishes, this is likely a leftover display issue. If the subagent really never starts, that’s a different bug, and it’s also worth filing a separate report.
Also seeing the same issue in 3.2. Subagent is running but its view cannot be loaded. It gets stuck at Loading Chat and then times out.
tbh it can be stuck at any stage now. starting subagent, grepping, writing files. anything. sometimes its the main agent, sometimes its the subagent. the new update is terrible. probably time to quit Cursor.
i have this issue as well.
Cursor is becoming the next MS.
Literally as I’m replying this thread, it get stuck again on grepping, and its not even a huge monorepo.