Terminal and agent interface not working for workspace until related Cursor workspace storage is manually deleted

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Terminal and agent interface not working for workspace until related Cursor workspace storage is manually deleted

I ran into an issue where a workspace would open but the integrated terminal panel never loaded and the agent terminal didn’t work either.
The editor itself was fine — files, sidebar, everything else worked — but no terminal, no agent, no search.
This persisted across Reload Window and full Cursor restarts, and happened even when the workspace was opened by itself.

I used my working Cursor instance with Opus4.6 to debug the bad instance, this is it’s findings:

Digging through the logs, the failure chain was:

  • The extension isolation service restarts extension hosts on window open
  • During that restart, anysphere.cursor-socket fails to activate
  • Without cursor-socket, the Connect transport provider never registers
  • This cascades: no search provider, git context times out, pty host never starts, terminal never loads
  • The broken state gets saved to the workspace’s state.vscdb, so every restart replays the same failure

The renderer.log for the affected window showed:
“No search provider registered for scheme: file, waiting”
“[WorktreeManager] Timed out waiting for git context provider”
“No Connect transport provider registered”

The exthost.log showed:
“Extension activation failure: anysphere.cursor-socket”
“Extension host terminating: renderer closed the MessagePort”

The ptyhost.log was completely empty (pty host never started).

The fix was to close Cursor and delete the workspace storage for the affected project:
rm -rf ~/.config/Cursor/User/workspaceStorage/workspace-id
rm -rf ~/.cursor/projects/home-user-project-name
Then reopen with: cursor /path/to/project

After that, everything worked immediately. The workspace initialized cleanly with terminal, agent, and search all functioning.

It seems like once the workspace state gets corrupted, there’s no built-in recovery — Reload Window and restarts just restore into the same broken state.
Ideally Cursor would detect this and reinitialize, or at least not persist a failed extension activation state.

Steps to Reproduce

Open the project in Cursor

Expected Behavior

Terminal and agents functional

Operating System

Linux

Version Information

Cursor 3.1.15

Does this stop you from using Cursor

Yes - Cursor is unusable

6

Hi there,

Thanks for the detailed report and especially for the thorough root cause investigation. Your diagnosis of the failure chain is really well documented.

You’re right that this is a real gap. Once the extension host fails to initialize, the broken state can get persisted and replayed on every restart, with no built-in recovery path. The workaround you found (deleting the workspace storage) is the correct fix for this situation.

For anyone else who runs into this, here’s a summary of the workaround:

Important: Deleting workspace storage will remove your chat history and workspace-specific state for that project. Back up these directories first if you want to preserve anything.

Linux:

rm -rf ~/.config/Cursor/User/workspaceStorage/<workspace-id>
rm -rf ~/.cursor/projects/<project-path>

Then reopen with: cursor /path/to/project

Our team is aware of related extension host initialization issues and is actively working on improvements. Your report highlighting the state persistence angle is particularly valuable.

To help us reproduce this internally, a few questions:

  1. What happened right before the issue started? Did Cursor crash, auto-update, or was there anything unusual (power loss, system update, etc.)? Or did it just appear out of nowhere on a normal launch?

  2. Do you still have the log files you referenced? Specifically the renderer.log, exthost.log, and ptyhost.log from the affected session. If you could share the full contents (or attach them), that would be extremely helpful for the engineering team to understand the exact failure path.

  3. Is the issue reproducible? If you open the same project now (after the fix), does it stay healthy, or has the issue returned?

7
  1. Cursor did crash, the computer froze before the issue, probably from maxed out resources from too many things running at once.
  2. No, log files are gone
  3. The original project is working fine. Another project was having a similar issue and just clearing out the workspaceStorage got it working again.
8

Thanks for the follow-up! The crash from resource exhaustion triggering the corrupted state is a helpful data point.

Unfortunate about the logs, but the fact that a second project hit the same issue (and the same fix resolved it) further confirms the pattern: a crash can leave workspace state in a broken configuration that doesn’t self-recover.

We’ll make sure the engineering team has this additional context, particularly the crash-triggered angle and the recurrence across multiple projects. If this keeps happening frequently, one thing that may help reduce the risk is keeping an eye on system resource usage when running Cursor alongside heavy workloads, though I realize that’s not always practical.

If it comes back again, feel free to post here or reach out. Glad the workaround is holding for now!