There seems to be inconsistency in the way remote control sessions are handled by Cursor depending on where they originated. I was hoping that I would be able to see these sessions in the IDE/editor agents sidebar regardless of their origin. Remote Control is enabled in Settings > Agents.
The 3 origins I’ve observed differing behaviours for:
[Works as expected] Starting a Remote Control session from web or mobile (e.g. <repo> @ Daniel's MacBook Pro) — the session appears as a web/cloud session in the IDE agents sidebar. Internally to the Cursor SQLite global state DB there is an entry in ItemTable in the composer.composerHeaders JSON referencing the background agent (createdFromBackgroundAgent) and bubbleId:* and composerData:* rows are in cursorDiskKV so the transcripts are saved locally (desirable).
[Unexpected behaviour] Starting a Remote Control session on “This Mac” from the Agents window — the session is not visible in the IDE agents sidebar. Internally to the Cursor SQLite global state DB there is no composer.composerHeaders entry nor any cursorDiskKV rows.
[Unexpected behaviour] Continuing an existing local IDE session on “This Mac” from the Agents window by selecting the session and using the dropdown at the bottom — the session is not visible in the IDE agents sidebar, however an archived version of the original local IDE session is. This is similar internally to the previous origin; in the Cursor SQLite global state DB there is the original archived composer.composerHeaders entry, but no new entry for the new remote control session nor any new cursorDiskKV rows.
Ultimately, I’d expect these to behave the same and be available for reading/replying in the IDE/editor agents sidebar. Hoping the details about the DB internals can help. Happy to locate/provide additional DB details if needed.
Hey, thanks for the detailed breakdown, especially the DB notes. That really helps clarify what’s not matching up.
What you’re seeing fits a known limitation: the Agents Window, including Remote Control on “This Mac”, and the editor agents sidebar currently sit on separate session stores. Remote Control sessions that start from web or mobile show up in the sidebar and get saved locally because they go through a separate path that writes the needed records. Sessions started or continued on “This Mac” from the Agents Window don’t use that path. That’s why there’s no entry in the sidebar, and why the transcript doesn’t end up in the local state DB.
Also, your third case, continuing on “This Mac” archives the original but doesn’t create a new local entry, looks like another part of the same local persistence issue.
Unifying these surfaces onto a shared store is something that’s being tracked, but I don’t have an ETA yet. Related threads if you want to follow along:
If you can add your Cursor version and, if you want, any extra DB details for the third case, I’ll attach it to the tracking. Let me know if any behavior differs from what I described.
For the third case continue on “This Mac” archives the original but doesn’t create a new entry, it’d be really helpful to get:
The composer.composerHeaders JSON for the original session before and after you click continue on This Mac. I want to see which flag or field marks it as archived.
Confirmation that the new continued session doesn’t create any new rows in cursorDiskKV (composerData:*, bubbleId:*), and also nothing anywhere else in the global state DB.
The composerId for the original session and, if it exists anywhere, the continued session, so we can match them up.
The session stays visible in the Agents Window, so it must be persisted somewhere. If you can find where its data is stored (another DB file or another store), that’d help a lot.
If it’s easier, send before and after snapshots for items 1 and 2 and I’ll attach them to the tracking. I don’t have an ETA for unifying these surfaces yet, but I’ll post in the thread if there’s an update.
cursorDiskKV only has the composerData:* and bubbleId:* for the original session ID
original:8e6babe6-2a93-4ca1-8c4e-e396351305e3
continued: still 8e6babe6-2a93-4ca1-8c4e-e396351305e3 (e.g. requests are made for GetOptimizedDiffDetails with "bcId": "bc-8e6babe6-2a93-4ca1-8c4e-e396351305e3")
Pretty sure it’s only visible because of the ListBackgroundComposers requests and the DB entries in cloudAgentRepository.agents.google-oauth2... which looks like
Thanks, this is exactly what I needed. The most important part is that the continued session reuses the same composerId (8e6babe6-...), and it lives in cloudAgentRepository.agents and gets pulled via ListBackgroundComposers, not through the composer store. That explains why there are no new composerData:* / bubbleId:* entries in cursorDiskKV, why the editor sidebar is empty, and why the only change in the original composer.composerHeaders is "isArchived": true.
I can see both attachments. I’ll add them to the tracking ticket along with these notes.
So this lines up with what I described earlier. The “This Mac” continue path doesn’t write a local record, so the transcript isn’t saved locally and the session doesn’t show up in the editor sidebar. We’re tracking work to unify these surfaces onto a shared store, but I can’t share an ETA yet. If I get an update, I’ll reply in the thread.
If you notice any behavior that doesn’t match this description, let me know.