Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
After opening a long-used workspace, Cursor loads into a half-booted state: the editor area works (files open, syntax highlighting, language servers run), but the entire bottom/side panel ecosystem fails to initialize.
Concrete symptoms:
- Integrated Terminal tab is blank — clicking “+” or any “Open Terminal” command does nothing.
- Output panel dropdown is empty — no channels listed at all (not even built-in ones like “Window”, “Main”, “Log”).
- Source Control view fails to render the SCM tree.
- Other tabs (Problems, GitLens) also empty / unresponsive.
Process inspection (ps -ax | grep -i cursor) confirms the ptyHost helper process never spawns, while all other helpers (renderer, GPU, fileWatcher, shared-process, 4× extension-host) are running normally with low CPU. So this is not a hang — a startup step is silently aborting.
renderer.log shows the trigger, repeated 21 times in the first second of window startup:
[warning] Unexpected error checking unified sidebar visibility: Index out of bounds
This is followed downstream (in the original 3.1.17 session before I auto-updated to 3.2.11) by:
[error] No Connect transport provider registered.
[error] Failed to refresh authentication, scheduling next attempt
Upgrading 3.1.17 → 3.2.11 cleared the No Connect transport provider cascade but did not fix the Index out of bounds issue.
exthost.log reveals the underlying cause — two extensions register views into secondary sidebar view containers that no longer exist:
[Anthropic.claude-code]: View container 'claude-sidebar-secondary' does not exist
and all views registered to it will be added to 'Explorer'.
[openai.chatgpt]: View container 'codexSecondaryViewContainer' does not exist
and all views registered to it will be added to 'Explorer'.
Cursor correctly logs a warning and falls back to Explorer at registration time, but the stale references persisted in this workspace’s state.vscdb from a previous Cursor version where these containers existed (or were named differently). On restore, the unified-sidebar layout array contains an index that points past the valid range → Index out of bounds → exception bubbles up → ptyHost spawn / OutputService channel registration / SCM view init never run.
This is per-workspace: my other workspaces with the same extensions installed open fine, because their state.vscdb doesn’t have the same stale view-location entries.
Note: this looks like the same root cause as a closed/inactive earlier report (Claude Code extension webview blank in bottom panel - “Index out of bounds” errors, Dec 2025, v2.2.20). The bug has now persisted for ~5 months across many releases, with a broader impact than the original report (terminal/output/SCM all affected, not just Claude Code webview).
Steps to Reproduce
Hard to reproduce from a clean install (likely needs the right sequence of extension upgrades + Cursor upgrades to seed the bad state). Path I can describe from my side:
- Use Cursor with extensions that contribute views to a secondary/separate sidebar container (in my case Anthropic.claude-code and openai.chatgpt) for an extended period.
- Cursor / extensions go through several major version updates that rename or remove view containers (claude-sidebar-secondary, codexSecondaryViewContainer are the two stale IDs in my db).
- Open the affected workspace → editor works, terminal/output/SCM panels are dead.
I can provide my pre-reset state.vscdb (5.3 MB, backed up before workaround) if you want to reproduce locally — let me know how to share it privately.
Workaround that fixed it for me:
# Quit Cursor first (Cmd+Q)
WS_HASH=<workspaceId> # find under ~/Library/Application Support/Cursor/User/workspaceStorage/
cd ~/Library/Application\ Support/Cursor/User/workspaceStorage/$WS_HASH
rm state.vscdb state.vscdb-shm state.vscdb-wal state.vscdb.backup
This loses only this workspace’s UI layout (panel sizes, recent tabs, etc.) — code, git, settings, extensions are untouched.
Expected Behavior
- Cursor should validate persisted view-location arrays against the current view-container registry on workspace restore, and silently drop entries pointing to no-longer-registered containers.
- The unified-sidebar restoration code path should be wrapped in try/catch so a failure cannot cascade into preventing unrelated subsystems (ptyHost spawn, OutputService channel registration, SCM init) from initializing.
- An ideal fix also auto-recovers: if Index out of bounds is caught, fall back to default sidebar layout for this workspace and continue startup.
Screenshots / Screen Recordings
Operating System
MacOS
Version Information
IDE:
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 25.3.0
Bug also reproduced on prior version 3.1.17 (same workspace, before today’s auto-update).
Additional Information
Relevant log file paths on macOS for anyone hitting this and checking their own setup:
Renderer log (where the Index out of bounds warning appears):
~/Library/Application Support/Cursor/logs//window1/renderer.log
Extension host log (shows the missing view-container warnings):
~/Library/Application Support/Cursor/logs//window1/exthost/exthost.log
Workspace state DB (the file to delete as workaround):
~/Library/Application Support/Cursor/User/workspaceStorage//state.vscdb*
The two extensions that contributed stale view-container IDs in my case:
Anthropic.claude-code → claude-sidebar-secondary
openai.chatgpt → codexSecondaryViewContainer
Other extensions in this window’s host (for completeness, in case the trigger needs a specific combo): eamodio.gitlens, dbaeumer.vscode-eslint, streetsidesoftware.code-spell-checker, kamikillerto.vscode-colorize, tamasfe.even-better-toml, anysphere.cursorpyright, rust-lang.rust-analyzer, vscode.git, vscode.github.
The two ChatGPT/Claude extensions are likely the trigger because they’re the ones the warnings name; the rest is environmental context.
Does this stop you from using Cursor
Sometimes - I can sometimes use Cursor