Extension agent panels cannot be docked in the secondary sidebar (reserved for Cursor Agent), leaving them stacked under the Explorer

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cross-reference: related to
UI Bug: Custom views stuck in Primary Side Bar / File Explorer (Reset View Locations not working),
now closed (auto-closed 2026-09-10 after 30 days of inactivity). That thread covered
3.10.17 ΓÇô 3.15.6 and named both the Claude Code and Codex extensions. This report is from
3.19.7 and 3.20.10, and the residual problem is different from the one fixed there.

Environment

  • Cursor 3.20.10, commit d6f462cdd0a6, VS Code 1.128.0
  • Windows 11 host, workspace opened over a WSL2 remote (Ubuntu 22.04)
  • anthropic.claude-code 2.1.266
  • Also reproduced on Cursor 3.19.7

What is actually wrong

An extension-contributed agent panel (here, Claude Code) can only live in the primary sidebar, where it stacks underneath the Explorer. It cannot be docked into the secondary sidebar, because that area is effectively reserved for Cursor Agent. There is no supported way to put the file tree on one side and a third-party agent panel on the other.

Dragging the panel toward the right silently does nothing: no drop indicator, no error, no
explanation. That silent no-op is the core usability complaint: it cost hours of troubleshooting
to discover the placement is disallowed rather than broken.

To be clear about what is not broken: on 3.20.10 the Explorer sits correctly in the left
primary sidebar, and views.customizations is now empty.

{"viewContainerLocations":{},"viewLocations":{},"viewContainerBadgeEnablementStates":{}}

ΓÇö so the “file tree orphaned into a generated container” failure from thread 165043 does appear
genuinely fixed. On 3.19.7 that key still held the broken state:

{"viewContainerLocations":{"workbench.views.service.sidebar.<uuid>":0},
 "viewLocations":{"workbench.explorer.fileView":"workbench.views.service.sidebar.<uuid>"}}

Supporting evidence

All values are live rows from User/globalStorage/state.vscdb → ItemTable on 3.20.10.

1. The secondary sidebar is occupied almost entirely by Cursor Agent

workbench.auxiliarybar.pinnedPanels contains 133 workbench.panel.aichat.* entries against
only 2 workbench.view.extension.* entries. Whether or not this is intended, the practical
result is that an extension panel has nowhere to go on the right.

2. Cursor forces the extension into its primary-sidebar variant

The Claude Code extension registers two mutually-exclusive containers: claude-sidebar under
when: claude-code:doesNotSupportSecondarySidebar, and claude-sidebar-secondary under the
negation of that key. Cursor sets the key, so the extension falls back to the Activity Bar
variant ΓÇö the one that stacks with the Explorer. Meanwhile all three of its containers carry
live, unhidden state:

workbench.view.extension.claude-sidebar.state.hidden
  -> [{"id":"claudeVSCodeSidebar","isHidden":false}]
workbench.view.extension.claude-sidebar-secondary.state.hidden
  -> [{"id":"claudeVSCodeSidebarSecondary","isHidden":false}]
workbench.view.extension.claude-sessions-sidebar.state.hidden
  -> [{"id":"claudeVSCodeSessionsList","isHidden":false}]

Containers whose when clause is unsatisfied are being left registered with active state rather
than dissolved.

3. The unified-sidebar cache references a container it does not pin

sidebar2.sidebarData.memoized.v1
  pinnedViewContainerIDs: [... "workbench.view.extension.claude-sidebar"]
  viewContainerOrders:    {"workbench.explorer": {...},
                           "workbench.view.extension.claude-sessions-sidebar": {...}}

It pins claude-sidebar but orders claude-sessions-sidebar, which is not in the pinned list.

4. Layout state contradicts itself

agentLayout.shared.v6       -> {"auxiliaryBarVisible":false,"auxiliaryBarWidth":0,
                                "sidebarVisible":false, ...}
workbench.auxiliaryBar.size -> 691

5. Three sidebar-location keys with undocumented precedence

cursor/agentLayout.sidebarLocation              -> left
cursor/agentLayout.sidebarLocationUser          -> left
cursor/agentLayout.sidebarLocationAgentOverride -> right

Earlier in the same session this was inverted ΓÇö sidebarLocation was right while the other two read left, and the sidebar rendered on the right against the stored preference. Nothing in the UI exposes these keys, documents which wins, or offers a reset.

Steps to Reproduce

Steps to reproduce

  1. Install the Claude Code extension and open its panel.
  2. Try to drag it into the secondary sidebar so the Explorer and the agent panel are on
    opposite sides.
  3. Observe: no drop target, no feedback, no state change. The panel stays stacked under the
    Explorer in the primary sidebar.
  4. Try View: Move View, View: Reset View Locations, and
    "workbench.sideBar.location": "left" ΓÇö none change the outcome.

Expected Behavior

Expected

Either the placement is allowed, or Cursor says it is not ΓÇö a disabled drop indicator, a
tooltip, or a message. Silently discarding the drag is the worst of the three.

Actual

Silent no-op, with no indication the placement is disallowed by design.

Workaround, for anyone who finds this thread

Confirmed working on 3.20.10. Do not fight the sidebar ΓÇö put the agent in an editor group
instead:

  1. Ctrl+Shift+P → Claude Code: Open in New Tab (claude-vscode.editor.open)
  2. Open any file, so the editor area is not left empty by the next step.
  3. Click the agent’s tab to make it the active editor.
  4. Ctrl+Shift+P → View: Move Editor into Right Group

Step 2 matters: with only the agent tab open, the command moves it right, the original group is
left empty, and VS Code deletes empty groups by default
(workbench.editor.closeEmptyGroups). The layout then looks unchanged and the command appears
broken, when in fact it did exactly what it was asked to do.

The Explorer keeps the full-height left sidebar, and the agent becomes a right-hand editor
column with noticeably more vertical space than it had stacked beneath the Explorer.
Claude Code: Open in New Window fully detaches it instead.

This is a good outcome and worth documenting. It is still a workaround, not the thing that was
asked for ΓÇö see the last request below.

Requests

  1. Give a visible reason when a view cannot be dropped, rather than a silent no-op.
  2. Dissolve view containers whose when clause is no longer satisfied instead of leaving them
    registered with live state.
  3. Document, or expose in the UI, the precedence among the three agentLayout.sidebarLocation*
    keys, and add a command to reset the unified-sidebar layout.
  4. The one that matters most: let third-party agent panels be used from the right-hand
    Agents surface again, alongside Cursor Agent. The editor-group workaround above is a fine
    fallback and I am productive with it, but it is a different thing from having the agent
    available on the right the way it used to be. Reserving that surface exclusively for Cursor
    Agent ΓÇö with no message explaining it ΓÇö makes a supported extension feel second-class in an
    editor that ships it.

Operating System

Windows 10/11
Linux

Version Information

Cursor IDE
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

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Hi @Jeremy.Chambers Thanks for the post! I double-checked this against Cursor 3.20.10 and Claude Code 2.1.266.

There are three separate behaviors here:

  1. Claude Code cannot register its own container directly inside Cursor’s Agent tab group. That restriction is intentional and is the behavior discussed in this thread.
  2. With the default horizontal Activity Bar, dragging the Claude Code panel toward the Secondary Side Bar does not initiate a cross-sidebar move. The lack of any feedback when that drag is rejected is a separate issue.
  3. View: Move View is different from dragging. It can move the individual Claude Code view into its own Secondary Side Bar entry, separate from Cursor’s Agent tab group.

For the Claude Code panel currently under Explorer, the exact path is:

  1. Run View: Move View.
  2. Select Claude Code under Side Bar / Explorer.
  3. Select New Secondary Side Bar Entry.

A completed move should open Claude Code on the right immediately and preserve that location across restarts. It will be a separate Secondary Side Bar entry, not a tab inside Cursor’s Agent group. Cursor may also switch its Agent area out of chat editor-tab mode while the extension view occupies that sidebar. That is expected compatibility behavior.

One useful clue is that your views.customizations snapshot is empty. A completed move would record both the moved view and its generated Secondary Side Bar container there. That means the snapshot does not show a successfully moved but hidden view. It shows that no custom move was persisted at the time of capture.

If the exact steps above still produce no visible change and views.customizations remains empty, please run Capture and Send Debugging Data immediately afterward and let me know when it completes. That would confirm a separate issue with the move command rather than the intentional Agent-tab restriction.

Your editor-group workaround is also valid and remains a good alternative when you want Claude Code beside your code without changing the Agent pane layout.