Cursor IDE and Agent conflict

[pageagency (AP)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I have an issue where at first the IDE and Agent started to drift. First everything I typed and all conversations from the IDE were also in the agent. Things that happen in the agent don’t to the IDE. This is also true if you pickup a session started in the IDE and and try and continue it in the agent. I regularly have had to just delete all the files and folders associated with cursor and start over.

I mostly develop via remote containers as some of the mono-repos i work on have several ports and need to be fully proxied to have a good dev environment. I think the issue comes from a discrepancy as to where the agent and the ide store data. At first blush it looks like data is stored in at least 5 places.

• local Windows 11: appdata/local/cursor and appdata/roaming/cursor
• remote host: /root/.cursor and /root/.cursor-server
• Container on the host: /root/ .cursor and /root/.cursor-server and /home/app/.cursor

I can’t open anything without it hanging and I see that multiple locations are touched during each attempt. The agent seems to have my history but just hangs and the IDE is show s black screen and hangs. If I use --classic, I can get the IDE to open with no history and it can no longer connect remotely.

I had previously fixed this, but an update today seems to have broken it again.

Is there something I am doing wrong? Is there a workaround? Where should the data be stored? How do I force a location?

Steps to Reproduce

Remote into a container use IDE and agent at the same time for different tasks.

Expected Behavior

Agent works autonomously from the IDE

Operating System

Windows 10/11
Linux

Version Information

Version: 3.20.10 (user setup)
VS Code Extension API: 1.128.0
Commit: d6f462cdd0a6a6d1cff570daf980e671d0a63de0
Date: 2026-09-10T21:04:54.045Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

Sonnet, GRok, Opus, Auto

Does this stop you from using Cursor

Yes - Cursor is unusable

UPDATE: Even with finally getting the agent closed, it is behaving like it still send everything to the agent.

What it looks like to me, is that the agent and ide or loosely connected and either need to be fully connected or fully independent. One is storing data in one of the 7 or 8 places and the other somewhere else. It appears both host root and container root are updated on every session and both have project folders matching the dates and time of one another.

[deanrie]

Hey, thanks for the detailed report. There are two different things here, so I’ll go through them one by one.

Where the data lives this is working as intended

Your chat history is stored locally on your Windows machine, not in the container and not on the remote host. Both the IDE and the Agents Window read from that same local storage. What you’re seeing is a filter, not two separate copies: the IDE sidebar only shows chats for the folder you currently opened, while the Agents Window shows all chats regardless of folder. So a chat started in the Agents Window will show up in the IDE only when the IDE has that same container folder open.

One important note for your dev container case: the IDE sidebar ties history to a folder using an internal workspace ID, which on Windows is computed from the folder path and its creation time. If the container was rebuilt or the folder got remounted, the path can stay the same but the workspace ID can become new. Then opening the same folder won’t show the old history in the IDE sidebar, even though the Agents Window still sees it. If you open the same folder and the IDE history still doesn’t appear, it’s more likely a workspace ID change than the filter. You can find the right folder under %APPDATA%\Cursor\User\workspaceStorage\ by checking workspace.json contents and confirming there’s a non empty state.vscdb.

The other folders you listed are normal:

• %APPDATA%\Cursor is settings and state, %LOCALAPPDATA%\Programs\cursor is the app itself, C:\Users\you\.cursor is extensions, mcp.json, rules.
• On the remote host and in the container ~/.cursor-server is the server Cursor downloads per version, one per version, so it gets re downloaded after each update, and ~/.cursor is mcp.json, rules, plugin cache, and transcripts on that machine. You see both /root/.cursor and /home/app/.cursor because some container steps run as root and the rest run as your remoteUser.

You don’t need to consolidate or force anything here, and deleting these folders will just make Cursor download the server again. Empty history with --classic is the same filter: that flag opens a fresh classic window, and chats will appear once you open the container folder in that window.

Freezes

It looks like the part of Cursor running inside the container the remote extension host is going unresponsive, and that blocks both the IDE and the Agents Window. Also, it started even before today’s update. Two things to check first: too many agents running at once in one window, and MCP servers that keep reconnecting or never connect.

Try these steps and tell me after which step the freezing goes away:

1. In the Agents Window, stop or archive agents you’re not using. Keep only one or two active.
2. Cursor Settings > MCP, disable servers that fail to start or keep reconnecting, including unreachable ones. If you use the Composio plugin MCP, temporarily disable it in Cursor Settings > Plugins too. Long plugin or MCP calls can block the extension host.
3. Reload the window using Ctrl+Shift+P then run Developer: Reload Window, then reconnect to the container.
4. Check if the container has CPU or memory limits in devcontainer.json or Docker settings. Fastest check is running docker stats on the host while Cursor is connected. If the container is hitting limits, raise them and reconnect.
5. If it still freezes after steps 1 to 4: while it’s frozen, run Ctrl+Shift+P then Developer: Show Running Extensions, click Extension Host (Remote), and also copy Output > Extension Host (Remote). Send both here along with docker stats output from that moment.

Separately about with --classic it won’t connect to remote, what exactly do you see: a spinner, an error, or the window never finishes loading? After an update the container needs to download a new ~/.cursor-server, so if the container has limited internet access, that’s the first thing I’d check.

Let me know how it goes.