Agents launched in Cloud via the Cursor mobile app or via Chrome browser do not appear in Cursor IDE’s Agents sidebar.
One of the key unlocks that Cursor 2 provided was being able to trigger a cloud agent to implement a plan from anywhere, such as the mobile app, before opening my laptop, opening Cursor, and picking up the cloud agent from there for any review or followups.
Now, agents launched in the cloud (in the same project) are not shown in the Agents window’s recent agents sidebar, meaning I have to use the mobile app or cursor.com/agents to even confirm that the Agent was ran and executed the request.
No evidence agent was created and ran in recent agents pane
Expected Behavior
I would expect to be able to load and review the cloud agent I created in the same project via the mobile app or Chrome browser in the Cursor desktop app
First thing to check, can you confirm you’re logged into the same account in Cursor IDE and on cursor.com/agents? Go to Cursor Settings gear icon > Account and check the email. It needs to match the account you use on the web or mobile app. If there’s a mismatch, agents from one account won’t show up in the other.
Also, make sure you’re on the latest version. You’re on 3.0.16, but 3.1.x is already rolling out and includes improvements to the Agents Window.
If the accounts do match and you’re still not seeing web or mobile started agents in the sidebar, let me know and I’ll flag it with the team.
“Custom task draft status”, “Members app renaming”, and "Healthcare service conditions list were all started in Cursor Agents Window and is shown on Chrome web app.
“Unified system for conventional commits” was local and therefore not expected to show in Chrome web app.
“Draft saving encounter” was started via the mobile app, and only shows on the Chrome web app, despite being in the same project. I cannot find or act on this Agent from the Agents window.
This is not a one-off issue-- I’m giving one example so as not to share more information than is necessary.
Hey, thanks for confirming and sharing the screenshots. The situation is clear, and this really looks like a bug on our side, not an account mismatch.
To help the team find the cause faster, can you share a couple details about the specific Draft saving encounter:
The URL of this agent on cursor.com/agents. The address will include bc-..., that’s the bcId we need.
Was the agent run as cloud, or as local via mobile forwarding to your Mac? The screenshot shows +1338 -56, so it did make changes. I mainly need to know where it was running.
Does restarting the IDE and resizing or reopening the Agents Window change anything?
Also, can you download the stable build from Cursor · Download and check if it reproduces there? Sometimes newer builds affect sidebar sync.
@harryfear thanks for the report and for the bcId.
Looks like this matches a case we already fixed with pagination for the cloud agents list in the sidebar. The sidebar was only fetching a limited window of the most recent agents, so some would disappear. The fix is already shipped in newer versions.
Can you both update to the latest stable from Cursor · Download and check if the missing agents show up in the Agents Window? @MishaTheMisha you were on 3.0.16, you can update via Cmd+Shift+P then “Attempt Update”, or download from the downloads page to get the latest version.
If web or mobile started agents still don’t sync on the latest stable, let me know and include the bcId of a specific missing agent and your Cursor version. I’ll open a separate ticket with those details.
@harryfear thanks for checking on 3.2.21. That means this isn’t the same bug we fixed with the pagination update. The fact that one auto-spawned cloud session (Setup Dev) is syncing while the others aren’t is a useful signal and helps narrow it down.
A few quick questions so we can open a separate ticket:
Roughly how many cloud agents do you have total on cursor.com/agents (like 10, 100, 1000+)?
Where were the missing agents started from: cursor.com/agents in a browser, mobile, via SDK, via automation, or a mix?
Do you currently have the same repo open in the IDE as the one that contains the missing agents on the web? And are you on the same branch, or a different one?
If you open DevTools Help > Toggle Developer Tools > Console and then refresh the Agents Window, do you see any red errors or warnings about listBackgroundComposers / BackgroundComposer? A screenshot or the last couple log lines would help.
Can you share the email on the account? If you don’t want to post it publicly, tell me and I’ll DM you so we can check on our side.
For @MishaTheMisha: if you’re still here, can you confirm if you can now see your web/mobile agents on 3.2.x? If yes, great. If not, same questions as above.
Once we have this, I’ll file a ticket with the bcId and details. No need for a video or Zoom yet, text details are enough to start.
(2) they were all started at `cursor.com/agents` (web UI)
[3] yes, same repo’s open and neither the IDE nor the web are in sync (2 different, exclusive on each); but the web ones auto-spawned their own branches, whereas the IDE is on main
Yep, on 3.4.20 and I’ve seen full resolution on the reported bug, plus a bug I hadn’t reported where the same cloud repo was being split into two groups in the Agents sidebar.
Thanks to the team for the resolution; feel free to close this ticket when opening a separate ticket for @harryfear .
@harryfear thanks for the details, that’s enough to open a separate ticket. Quick note on the screenshot. That’s the console for cursor.com/agents in the browser, but the request was about DevTools inside the Cursor IDE. Use Help > Toggle Developer Tools in the IDE, not Chrome. Those two web errors, React #418 hydration and the 401 on get-team-commands, are not related to the cloud agents listing. get-team-commands is a different feature, team commands. It looks like you just don’t have permissions or a team set up there, and the UI is pinging it anyway. Not a blocker.
What would be helpful to add:
Open DevTools inside the IDE via Cmd+Shift+P then Developer: Toggle Developer Tools, switch to the Network or Console tab, refresh the Agents window, and share what comes back for listBackgroundComposers, or any red errors next to it.
Quick experiment. In the IDE, switch to the branch one of the cloud agents worked on, for example cursor/mhh-json-edits-eebf, and check if it shows up in the sidebar. We want to see if the client is filtering by the current branch.
I’ll open a ticket with the bcId you already shared plus these details. I can’t give an ETA yet, I’ll post an update here once I have one.
@harryfear thanks for the screenshot and for the answer on (2). The fact that IDE → web sync works but web → IDE doesn’t is a useful signal.
The screenshot from IDE DevTools is correct. But the visible errors (listTeamEnvironmentsinvalid_argument and getTeamCommandsunauthenticated) are about other features (team environments, team commands). The cloud agents list is fetched via listBackgroundComposers, and I can’t see it in the frame. It might be succeeding but returning the wrong data.
Can you check two things:
In DevTools, open the Network tab, type listBackgroundComposers in the filter, then refresh the Agents window (for example collapse and expand the panel). You should see a request, open it and check the Response. If there are multiple, send all of them. A screenshot is fine.
That experiment from the previous message, switch the IDE to a branch where one of the cloud agents was running (for example cursor/mhh-json-edits-eebf), and see if it shows up in the sidebar. I want to check if the client filters by the current branch.
Also, quick question: are you on solo Pro or a team member plan right now? Those team-member errors in the logs hint at solo, and then the issue might be how the IDE scopes requests for solo users. Misha was in the Benchmark Health team and it was resolved on 3.4.20. Your case looks different, so I want to confirm.
Interestingly, I’m not getting ANY `ListBackgroundComposers`.
Can you clarify (2)? I don’t get it. You mean launch a new Local agent with a cloud branch? I can’t. It switches me to cloud. It seems to know that branch was cloud-originated?
If nothing shows up in the Network tab for ListBackgroundComposers, there are two things to check:
Case matters, DevTools filtering is case-sensitive. Try lowercase listBackgroundComposers, or just BackgroundComposers, or Composer. Also make sure the Network tab is actually recording requests, recording is on, you’re not looking at old logs because Preserve log is on, and the filter is set to All and not XHR only.
Once the filter is correct, collapse and expand the Agents panel, or run Command Palette → Developer: Reload Window. The request should fire when the panel initializes. If it’s still totally quiet even with the right filter, that’s a clue by itself and it means the client isn’t making the list call.
If you do find the request, open it. In Response you should see an array of agents. Send a screenshot or paste the content, you can redact IDs except bcId. If the array is empty or your web agents aren’t there, it’s backend-side. If they are there but still don’t show in the sidebar, it’s likely a client-side filter.
About experiment (2), I didn’t explain it well, sorry. You don’t need to run a local agent. Just do a normal git checkout cursor/mhh-json-edits-eebf from the terminal or Source Control panel, or any branch a cloud agent worked on. After checkout, see if the matching cloud agent appears in the sidebar. The goal is to check if the client filters agents based on the current IDE git branch.
Last thing, are you on solo Pro or on a team plan? I saw team-member errors in the logs, so I want to confirm since scoping might differ for solo users.
Once we have this, I’ll open a ticket with your request id and the details.
Good catch, thanks. The fact that there are zero listBackgroundComposers requests is a symptom, and the root cause is most likely already visible in the Console above: This document requires 'TrustedScript' assignment. The action has been blocked. There are 13 identical errors, and the stack traces include composer/browser/... and aiBackgroundComposer/browser/backgroundComposerDataService.js. So the code that should make the list request never gets a chance to initialize because it’s being blocked by a Trusted Types policy.
To figure out where the policy is coming from, can you check a couple things:
Full version info from Help > About or Cmd+Shift+P → About. I want to confirm you’re on a current Cursor version, not 3.5.11.
Open Agents Window and check the Console. If the TrustedScript errors are gone and cloud agents show up, then some extension is injecting a CSP or Trusted Types policy. If so, share the list of enabled extensions via Cmd+Shift+P → Extensions: Show Installed Extensions.
If the errors still happen with extensions disabled, it’s more likely a regression in the Cursor build itself. In that case, try reinstalling the latest stable from Cursor · Download over your current install.
If you’re on a managed work Mac, check whether there are any MDM profiles that enforce Chromium policies: System Settings → Privacy & Security → Profiles.
Once you’ve got the results, I’ll open a separate ticket with that info and the bcId you already shared. I can’t give an ETA, but without a repro in a clean environment, progress will be slow.
Popping in to say that there are definitely sync issues here with the Cursor Agents window and Cursor Web viewer.
For whatever reason around ~25% of cloud agents created on the Cloud Web viewer never appear in Cursor Agents window.
I also notice that when quitting and re-opening Cursor Agents I can lose Cloud Agent sessions which I was successfully working with in Cursor Agents, and can only reach them from that point on using the web interface
I’ll note that I do also have the TrustedScript error along with many others
workbench.desktop.main.js:36073 This document requires 'TrustedScript' assignment. The action has been blocked.
(anonymous)
@
workbench.desktop.main.js:36073
get value
@
workbench.desktop.main.js:36073
(anonymous)
@
workbench.desktop.main.js:36093
i
@
workbench.desktop.main.js:36073
(anonymous)
@
workbench.desktop.main.js:36095
i
@
workbench.desktop.main.js:36073
ZodObject
@
workbench.desktop.main.js:36073
TDk
@
workbench.desktop.main.js:36095
out-build/vs/workbench/contrib/composer/browser/composerHeaderStorageUtils.js
@
workbench.desktop.main.js:36098
(anonymous)
@
workbench.desktop.main.js:5
out-build/vs/workbench/contrib/composer/browser/composerDataCreation.js
@
workbench.desktop.main.js:36107
(anonymous)
@
workbench.desktop.main.js:5
out-build/vs/workbench/contrib/composer/browser/composerDataHandle.js
@
workbench.desktop.main.js:36162
(anonymous)
@
workbench.desktop.main.js:5
out-build/vs/workbench/contrib/aiBackgroundComposer/browser/backgroundComposerDataService.js
@
workbench.desktop.main.js:36162
(anonymous)
@
workbench.desktop.main.js:5
(anonymous)
My device does have an MDM profile, so the code needs to fall back gracefully if TrustedScript is not possible.
Hopefully can get addressed as means I am now keeping a mental model of which agents are / are not bugged out and are reachable only from the web interface!
Hey, thanks for the screenshot, that clears things up. I can see you’re on 3.6.31, and the key detail is this: the Function constructor call is getting blocked with does not accept TrustedString arguments because of a Trusted Types policy your MDM is enforcing. Because of that, the composer init code crashes and the request for the cloud agent list never goes out, which is why the web and mobile agents disappear from the sidebar. Another user in the thread sees the same thing on a managed device, so the cause is clear now.
That’s enough to open a ticket. I’ll include your log, stack trace, and version. I can’t share an ETA yet, but I’ll post in the thread once I have an update.
One quick check if you don’t mind, it’ll help narrow down where the policy comes from. Launch Cursor with extensions disabled:
Then check if the TrustedScript errors still show up in Console. If they go away, an extension is injecting the policy. If they stay, which is more likely with MDM, it’s the environment or the build. Not a blocker, I’ll file the ticket either way.
