Glass/Agents layout: per-chat terminal panel missing after switching sidebar conversations

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

In Cursor 3.x Glass (Agents Window) layout, each agent chat used to keep a sticky terminal panel on the right. After recent updates, switching between chats in the left sidebar (including across different workspace folders/projects) sometimes returns to a chat where the agent conversation is still there, but the associated terminal panel is gone.

This is not just blank terminal text (a rendering issue). The whole terminal pane for that chat is missing or not rebound. The chat history and agent UI load fine; only the per-conversation terminal state fails to restore.

This breaks multi-project workflows where you keep parallel agent sessions with running terminals and expect each chat to restore its own terminal when you click back to it.

Steps to Reproduce

  1. Open Cursor in Glass/Agents mode (glassMode: true).
  2. Use layout with chat/agent list on the left sidebar and integrated terminal on the right.
  3. Open Project A (e.g. one repo folder), start an agent chat, let the agent run shell commands so a terminal session is active on the right.
  4. Open Project B (different folder), start another agent chat with its own terminal activity.
  5. Switch back and forth between chats via the left sidebar (within the same project or across projects).
  6. After several switches (intermittent; not always on the first switch), return to a chat that previously had a visible terminal.

Observed: chat/conversation UI and history remain, but the right-side terminal panel is missing. Sometimes the panel can be forced back via Terminal menu, but the original per-chat terminal binding/session is lost.

Expected Behavior

When re-selecting an agent chat in the sidebar, Cursor should restore that conversation’s bound terminal panel and terminal session state, the same way it did in earlier builds. Each composer/chat should have independent, persistent terminal layout state across sidebar navigation.

Operating System

Windows 10/11

Version Information

Version: 3.8.16
VSCode Version: (Cursor 3.8.16 build)
Commit: 6064a4a629d1bc5b421bce9e9dc8c5967c111640
Release Track: dev
Electron/Chromium: bundled with Cursor 3.8.16
OS: Windows 10 Pro 10.0.19045 x64

For AI issues: which model did you use?

Composer 2.5 (Agent mode) — issue is UI/layout, not model-specific

Additional Information

Layout: Glass/Agents Window (glassMode: true in storage.json). Chat list left, terminal right.

Shell: PowerShell (WSL/Git Bash profiles also configured).

GPU: NVIDIA GeForce GTX 1660 SUPER (32.0.16.1047) + Intel UHD Graphics 770 (32.0.101.7085).

Relevant settings: update.releaseTrack: dev, cursor.terminal.usePreviewBox: true, cursor.agent_layout_browser_beta_setting: true.

Local state evidence (may help debug): Per-agent panel visibility is stored in globalStorage/state.vscdb under keys like glass/cursor.editorPanelVisibility.agent/{composerId} with {visible: boolean, updatedAtMs}. On this machine, 19 chats have visible: true and 2 have visible: false, suggesting per-composer terminal panel state is tracked but not always restored correctly on chat switch.

Related forum threads (similar but not identical):

  • UI constantly resets layout in Cursor 2.0 (#139511) — terminal panel vanishes
  • Non-sticky editor layout (#157201) — layout state not persisted across mode switches
  • Secondary sidebar terminal regression (#149126) — terminal/chat tab routing issues on right panel
  • Integrated Terminal Text Disappears When Switching to AI Chat (#138096) — rendering bug, distinct from whole panel missing

Workarounds tried / partial:

  • Terminal menu → New Terminal sometimes restores a panel but not the original per-chat session
  • glass.toggleTerminal may show a terminal but not rebind the chat-specific one
  • GPU acceleration off / Legacy Terminal Tool — addresses rendering freezes, not this layout persistence issue

Request: Please treat this as a Glass per-composer layout/terminal binding regression. Happy to provide state.vscdb excerpts if needed.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey, thanks for the report. It’s really detailed, and extra thanks for the repro steps and for digging into the editorPanelVisibility.agent/{composerId} keys. That helps a lot.

This is an area where we already have a few related reports about panels restoring when switching between chats in the Agents Window, but we haven’t been able to reproduce this exact case where the terminal panel fully disappears after switching in the sidebar. It looks like a client-side layout state issue, and we don’t see anything on the server side, so it’s hard to move forward without a repro.

To speed this up, you mentioned you can share a screen recording and an excerpt from state.vscdb. If you can, please send:

  • A short screen recording of the moment the panel disappears, so we can see how many switches it takes and the scenario, like single project or across projects.
  • An excerpt of glass/cursor.editorPanelVisibility.agent/{composerId} for a couple of chats where the bug happened, with the visible and updatedAtMs values before and after switching if possible.

I’ve filed an internal issue for this specific variant. I can’t share an ETA for a fix yet, but I’ll post an update in the thread if we have one.

6

Follow-up with additional symptoms and the state.vscdb excerpt you asked for.

**Frequency:** Several times per day.

**Strongest repro pattern:**

1. Have 2 agent chats active in the sidebar (often across projects, e.g. hermes + another repo).

2. Each chat has its own terminal on the right, agents running shell work in parallel.

3. Work in chat B for ~15-30 minutes.

4. Click back to chat A in the sidebar.

5. Chat A loads fine (history, agent UI) but the terminal that was running there is gone. I did not close it.

**Additional symptom - terminal identity gets crossed:**

Sometimes when I click into a sidebar chat, the terminal panel shows a name/label from a different chat. If I then go back to the original chat, that chat’s terminal is missing entirely. Per-chat terminal mapping seems to get confused, not just hidden.

**Live example (happening right now):**

- Sidebar chat (web3sec) general under hermes selected - had a terminal on the right running agent work.

- hermes main workspace chat also had its own terminal.

- Both terminals disappeared from the UI at the same time without me closing either. Right panel is empty.

**state.vscdb excerpt (pulled while bug is active):**

```

glass/cursor.editorPanelVisibility.agent/c26e779c-10c8-44b8-9750-c2219ddd3ca2

visible: true

updatedAtMs: 2026-06-20 18:42 UTC

workspace: c:\Users\PC\Documents\GitHub\hermes\agents\web3sec

→ web3sec general chat. Terminal NOT shown in UI.

glass/cursor.editorPanelVisibility.agent/c824a66a-8c59-4815-995e-2e852b5a5f8c

visible: true

updatedAtMs: 2026-06-20 18:42 UTC

workspace: c:\Users\PC\Documents\GitHub\hermes

→ hermes main chat. Terminal NOT shown in UI.

```

Both composers have visible: true in persisted state while the terminal panel is empty in Glass. Looks like a state/render desync - layout state thinks the panel should be visible but the terminal is not bound or not rendered.

Only 2 composers on this machine have visible: false (older/draft chats). The currently affected chats still read visible: true.

Other relevant keys:

- terminal.hidden: [{“id”:“terminal”,“isHidden”:false}]

- cursor/terminalExecutionServiceV3HealthCheckResult: passed

Happy to pull before/after snapshots for specific composer IDs on request.

7

Update after full Cursor restart:

Symptom is gone for now. I have (MAIN) hermes and (web3sec) general both with running terminals, swapping back and forth in the sidebar, and the UI looks correct.

However I ran a local state dump while the UI is healthy, and the workspace-level DB still looks odd. So workspace SQLite may not be a reliable indicator of whether Glass terminals are actually bound/rendered.

**Baseline dump (UI healthy, terminals visible, 2026-06-21 ~00:43 UTC):**

```

GLOBAL web3sec (c26e779c…): editorPanelVisibility.visible = true

GLOBAL hermes (c824a66a…): editorPanelVisibility.visible = true

WORKSPACE web3sec:

cursor/agentLayout.panelVisible = false

terminal = {“terminal”:{“collapsed”:false,“isHidden”:true}}

terminal.integrated.layoutInfo = MISSING

WORKSPACE hermes:

cursor/agentLayout.panelVisible = false

terminal = {“terminal”:{“collapsed”:false,“isHidden”:true,“size”:2235}}

terminal.integrated.layoutInfo = {“tabs”:[]}

workbench.panel.hidden = true

```

So when the bug was active earlier, we had a similar workspace DB shape PLUS an empty right panel in the UI. After restart, similar DB shape but UI is fine.

Implication: the failure may be in Glass render/binding lifecycle (or a missing layout cache — I see repeated `LayoutStateModel.load detected missing workspace layout cache` in Cursor Structured Logs on workspace open), not simply `editorPanelVisibility.visible=false` in global state.

I will run the same dump again next time the UI breaks (before restart) and post a broken vs healthy pair. Script: dump `glass/cursor.editorPanelVisibility.agent/*` from globalStorage/state.vscdb plus workspace keys `cursor/agentLayout.panelVisible`, `terminal`, `terminal.integrated.layoutInfo`.

8

Just reproduced again (~2 min after restart baseline). This is the **wrong-terminal-bound** variant.

**Repro (just now):**

1. Had (web3sec) general and (MAIN) hermes both with running terminals, swapping fine.

2. Switched away, then clicked back to **(MAIN) hermes** in sidebar.

3. Right panel initially showed **Changes**, not Terminal.

4. Clicked Terminal tab in the right panel header.

5. Terminal list shows **2 terminals: `web3sec` + empty `powershell`** — but selected sidebar chat is **(MAIN) hermes**.

6. The hermes terminal that was running before is gone. Wrong chat’s terminal is showing instead.

Screenshot: Screenshot - 349e14102cf3d7f3f6baad57894685d5 - Gyazo

**State dump taken while bug is active (UI wrong, 2026-06-21 00:49 UTC):**

```

GLOBAL web3sec: editorPanelVisibility.visible = true (updated 00:48:44)

GLOBAL hermes: editorPanelVisibility.visible = true (updated 00:48:39)

WORKSPACE hermes (selected chat):

cursor/agentLayout.panelVisible = false

terminal.isHidden = true

terminal.integrated.layoutInfo.tabs = [] # no tabs registered for hermes workspace

terminal.numberOfVisibleViews = 1 # but UI shows 2 terminals incl web3sec

```

So the UI is showing a **web3sec-named terminal while hermes composer is selected**, and workspace DB has **zero terminal tabs** for hermes. Looks like Glass is rendering a stale/wrong terminal from another composer instead of restoring the bound one.

Compare to healthy baseline from post #7 ~6 min earlier: same workspace DB shape but UI was correct. So the DB alone doesn’t predict the bug — something in the Glass terminal switch/render path is losing the per-composer binding.

9

Thanks for the detailed follow-ups. The state dumps, screenshot, and the broken vs healthy comparison really help.

The crossed terminal identity case, where the selected chat shows the terminal from another composer, is a new and useful signal. I added it to the internal issue along with your data: visible: true in global state while the panel is empty, LayoutStateModel.load detected missing workspace layout cache in Structured Logs, and terminal.integrated.layoutInfo.tabs = [] for the affected workspace. The fact that the workspace SQLite looks the same in both the broken and healthy state is noted too. That points more to the Glass render or binding lifecycle, not just a visibility flag.

If you can, please grab that broken vs healthy pair of dumps you mentioned, using the same composer ID before and after the panel breaks. Also, if you catch it, a short screencast of the transition where the terminal disappears or gets swapped would be great. That’s the best way to help us move toward a reliable repro on our side.

I can’t share an ETA for a fix yet, but if there’s an update, I’ll reply in the thread.

12

Thanks Dean — the broken vs healthy pair is already in the thread from the same session (~6 min apart, same composer IDs). Collating it here in one place for the internal issue.

**Composer IDs (stable across both dumps):**

- hermes (MAIN): `c824a66a-8c59-4815-995e-2e852b5a5f8c`

- web3sec (general): `c26e779c-10c8-44b8-9750-c2219ddd3ca2`

-–

**HEALTHY — post #7, 2026-06-21 ~00:43 UTC**

UI: both chats have terminals, swapping back and forth works.

```

GLOBAL hermes (c824a66a):

editorPanelVisibility.visible = true

WORKSPACE hermes (9ff23b98…):

cursor/agentLayout.panelVisible = false

terminal.isHidden = true

terminal.integrated.layoutInfo.tabs = []

workbench.panel.hidden = true

```

-–

**BROKEN — post #8, 2026-06-21 ~00:49 UTC (same composers, ~6 min later)**

UI: selected (MAIN) hermes, but terminal list shows web3sec + empty powershell. Hermes terminal gone.

Screenshot: Screenshot - 349e14102cf3d7f3f6baad57894685d5 - Gyazo

```

GLOBAL hermes (c824a66a):

editorPanelVisibility.visible = true (updated 00:48:39)

WORKSPACE hermes (9ff23b98…):

cursor/agentLayout.panelVisible = false

terminal.isHidden = true

terminal.integrated.layoutInfo.tabs = []

terminal.numberOfVisibleViews = 1 # UI showed 2 terminals incl web3sec

```

-–

**Takeaway:** workspace SQLite is effectively identical healthy vs broken. Global editorPanelVisibility stays true. The only change is what Glass renders — wrong terminal bound, or panel on Changes tab instead of Terminal. That matches your render/binding lifecycle theory.

**Structured log (repeated on workspace open):**

`LayoutStateModel.load detected missing workspace layout cache`

Path: %APPDATA%\Cursor\logs\\window*\exthost\anysphere.cursor-always-local\Cursor Structured Logs.workspaceId-9ff23b98…log

**Screencast:** didn’t capture the transition live — bug is intermittent and the swap happens on a single sidebar click. I have the Gyazo end-state screenshot (post #8). Next time it happens I’ll try Win+Alt+R before touching anything else to catch the click → Changes tab → wrong terminal sequence.

**Dump script** (run before restart when UI breaks):

`python agents/web3sec/runs/cursor-terminal-state-dump.py broken`

Reads global `glass/cursor.editorPanelVisibility.agent/{composerId}` + workspace `cursor/agentLayout.panelVisible`, `terminal`, `terminal.integrated.layoutInfo`.

13

Thanks for putting the broken vs healthy pair together in one place, it’s way easier to work with internally.

The main takeaway matches what we suspected: the workspace SQLite is basically the same in both states, the global editorPanelVisibility.visible stays true, and the only thing that actually changes is what Glass renders (someone else’s terminal in the binding, or the Changes panel instead of Terminal). That points to a render or binding lifecycle issue, not a visibility flag. I also added the stable composer IDs and LayoutStateModel.load detected missing workspace layout cache from Structured Logs to the issue.

A screencast of the actual transition (click → Changes tab → someone else’s terminal) would still be helpful if you can catch it with Win+Alt+R before you touch anything else. That’s the best chance for us to turn this into a stable repro.

I can’t share an ETA for a fix yet, but if there’s an update, I’ll reply in the thread.

14

I’m having a similar issue:

Title: Glass/Agents layout: Browser panel disappears or switches away when changing chats

Category: Bug Reports → Agents Window / Layout

Where does the bug appear?

Cursor IDE — Glass / Agents Window

Describe the Bug

In Glass (Agents Window), I keep the Browser panel open on the right (previewing localhost:1985 prototypes). When I switch chats in the left sidebar or start a new chat, the Browser panel is often removed entirely or replaced with another right-panel tab (e.g. Changes). The chat history loads fine; only the per-conversation right-panel state fails to restore.

This appears to be the same class of issue as the terminal panel regression in this thread, but affecting the Browser tab specifically.

Observed symptoms:

  • Browser panel vanishes after switching chats
  • Right panel jumps to Changes (or another tab) instead of Browser
  • Happens when creating a new chat, not only when switching existing ones
  • Intermittent but frequent enough to block multi-chat prototype workflows

Steps to Reproduce

  1. Open Cursor in Glass/Agents mode (cursor/firstWindowOpenGlassTreatment: true on my machine).
  2. Open workspace proto-plugin (/Users/maayanalbert/Documents/proto-plugin).
  3. Start an agent chat; open the Browser panel on the right and navigate to a prototype (e.g. http://localhost:1985/prototypes/event-types).
  4. Start a second agent chat (or switch to an existing one) via the left sidebar.
  5. Switch back to the first chat, or continue switching between chats.

Observed: Browser panel is gone or a different right-panel tab is shown. Chat/conversation UI remains.

Expected Behavior

Re-selecting an agent chat should restore that chat’s right-panel layout — including which tab was active (Browser) and the browser view — the same way per-chat terminal state is intended to work.

Operating System

macOS (darwin 25.5.0, arm64)

Version Information

  • Cursor: 3.10.17 (stable)
  • Layout: Glass/Agents Window, sidebar left
  • Workspace ID: 2278f50ce82d4f3bdce8ff4ed65d0825 (proto-plugin)

Additional Information

Local state evidence (captured 2026-07-06):

Per-composer panel visibility is stored in globalStorage/state.vscdb under keys like glass/cursor.editorPanelVisibility.agent/{composerId}:

Total keys: 597

visible: true → 536

visible: false → 65

Sample value: {“visible”:true,“updatedAtMs”:1783386050752}

Recent composers with visible: true (panel should be shown):

  • c5c67a90-052c-4b14-99b1-edf3089a7e44
  • 48927a79-8e96-4be6-b6aa-d73f1d21a187
  • 1ac577c2-59bb-4594-a3e1-f8445fb9357e

Layout geometry is stored in a shared global key (not per-composer):

agentLayout.shared.v6 = {“auxiliaryBarVisible”:false,“panelVisible”:true,“sidebarVisible”:false,…}

Workspace-level state (workspaceStorage/2278f50ce82d4f3bdce8ff4ed65d0825/state.vscdb):

cursor/agentLayout.panelVisible = true

terminal.isHidden = true

workbench.panel.hidden = false

Hypothesis: Per-composer editorPanelVisibility.visible says the panel should be visible, but Glass’s render/binding lifecycle fails to restore the correct right-panel tab (Browser) on chat switch — similar to the terminal desync described in the linked thread.

Structured logs: On prior workspace opens I have seen:

LayoutStateModel.load detected missing workspace layout cache

(e.g. Cursor Structured Logs.workspaceId-2278f50ce82d4f3bdce8ff4ed65d0825.*.log)

Browser MCP registry (healthy at time of report — separate from this bug):

  • 2 active glass-browser-* tabs on localhost:1985
  • No phantom/orphan tab handles

Related thread: Per-chat terminal panel missing after switching sidebar conversations — Cursor staff filed an internal issue for render/binding lifecycle failures with visible: true in global state while the panel is empty or wrong.

Workarounds tried:

  • Re-clicking Browser in the right panel header (sometimes works, often doesn’t)
  • Cmd+Shift+M full-screen browser (helps stay on page but doesn’t fix restore on switch)
  • External browser for localhost (only reliable workaround)

Happy to provide a broken vs healthy state dump pair and a screen recording of the sidebar click → panel gone transition if that helps reproduce.

Does this stop you from using Cursor?

Sometimes — I can use Cursor, but multi-chat agent + browser preview workflows are unreliable.

Shorter version (Help → Report Bug)

Summary: Browser panel in Glass disappears or switches to another tab when I change chats or start a new chat.

Steps:

  1. Glass/Agents mode, Browser open on right (localhost:1985)
  2. Switch chats in left sidebar or create new chat
  3. Browser panel gone or wrong tab shown; chat history intact

Expected: Each chat restores its Browser panel state on switch.

Actual: Panel removed or replaced (often Changes).

Environment: macOS arm64, Cursor 3.10.17, workspace proto-plugin (2278f50ce82d4f3bdce8ff4ed65d0825).

Evidence: 597 glass/cursor.editorPanelVisibility.agent/{composerId} keys in global state (536 visible: true); shared agentLayout.shared.v6 layout; likely same render/binding bug as forum thread 163709 but for Browser tab.

Impact: Blocks keeping a prototype preview visible while hopping between agent chats.

Capture script (run when the bug happens)

Save this and run it while the UI is broken, before restarting Cursor. Cursor staff specifically asked for broken vs healthy pairs.

#!/usr/bin/env bash

# cursor-glass-panel-dump.sh [broken|healthy]

LABEL=“${1:-snapshot}”

TS=$(date -u +%Y%m%dT%H%M%SZ)

OUT=“$HOME/Desktop/cursor-glass-panel-$LABEL-$TS.txt”

GLOBAL=“$HOME/Library/Application Support/Cursor/User/globalStorage/state.vscdb”

WS=“$HOME/Library/Application Support/Cursor/User/workspaceStorage/2278f50ce82d4f3bdce8ff4ed65d0825/state.vscdb”

{

echo “label=$LABEL captured=$TS”

echo “cursor_version=$(defaults read /Applications/Cursor.app/Contents/Info.plist CFBundleShortVersionString 2>/dev/null)”

echo

echo “=== GLOBAL: editorPanelVisibility counts ===”

sqlite3 “$GLOBAL” “SELECT json_extract(value,‘$.visible’), COUNT(*) FROM ItemTable WHERE key LIKE ‘glass/cursor.editorPanelVisibility.agent/%’ GROUP BY 1;”

echo

echo “=== GLOBAL: 5 most recent visible=true ===”

sqlite3 “$GLOBAL” “SELECT key, value FROM ItemTable WHERE key LIKE ‘glass/cursor.editorPanelVisibility.agent/%’ AND json_extract(value,‘$.visible’)=1 ORDER BY json_extract(value,‘$.updatedAtMs’) DESC LIMIT 5;”

echo

echo “=== GLOBAL: agentLayout.shared.v6 ===”

sqlite3 “$GLOBAL” “SELECT value FROM ItemTable WHERE key=‘agentLayout.shared.v6’;”

echo

echo “=== WORKSPACE proto-plugin ===”

sqlite3 “$WS” “SELECT key, value FROM ItemTable WHERE key IN (‘cursor/agentLayout.panelVisible’,‘terminal’,‘terminal.integrated.layoutInfo’,‘workbench.panel.hidden’);”

} > “$OUT”

echo “Wrote $OUT”

Usage:

chmod +x ~/Desktop/cursor-glass-panel-dump.sh

~/Desktop/cursor-glass-panel-dump.sh broken # when panel is gone

~/Desktop/cursor-glass-panel-dump.sh healthy # after you reopen Browser manually

15

Hey, thanks for the detailed report, and especially for the state-dump pair, the script, and the breakdown of the editorPanelVisibility.agent/{composerId} keys. That’s super helpful.

You’re right that it’s the same class of issue (render or binding when switching chats in the Agents Window), but it’s basically a separate variant. This thread is about the terminal panel, and in your case the Browser tab disappears or switches. To avoid mixing data and to track the Browser variant properly, please create a separate thread for it in Bug Reports. Feel free to reuse what you already wrote, it’s great.

In the new thread, please include if you can:

  • A broken vs healthy pair of dumps for the same composer ID, before and after the panel breaks, like you already did for the terminal.
  • A short screencast of the transition, click in the sidebar then Browser disappears or switches to Changes. On macOS it’s easy to record with Cmd+Shift+5. This is the best chance for us to get a stable repro.

Once the thread is up, I’ll link it to the right internal issue. I can’t share an ETA for a fix yet, but I’ll follow up if there’s an update.

16

Where does the bug appear (feature/product)?

Somewhere else…

Describe the Bug

Agent Window

I’m on Windows and using the Agents Window. I work with a terminal with claude code in my agents, but when I have two or more agents from the same or different projects, sometimes I go to another agent and the terminals get reloaded and I lose my CC session or any other process that was running on it.

Steps to Reproduce

  1. Open 2 or more agents
  2. Open a terminal on each agent
  3. Trigger a long running process on each terminal
  4. Jump between agents, at some point you will see that any of the agents get its terminals reloaded.

Expected Behavior

Terminal session should not get reloaded when jumping between agents.

Operating System

Windows 10/11

Version Information

Version: 3.10.20 (user setup)
VS Code Extension API: 1.125.0
Commit: 23b9fb205fe595ea2be29da7214e19762d037fc0
Date: 2026-07-07T07:03:33.071Z
Layout: Agent Window
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Windows_NT x64 10.0.26200

Additional Information

I’m using Powershell 7 and Windows Terminal

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor