API: expose panel/sidebar/auxiliaryBar visibility state to extensions

Open
#321,409 4 comments 20 reactions 1 assignee View on GitHub

@benibenj is already working on this.

Since Jun 16, 2026.

Assessment

This issue has not been assessed yet.

Description

api feature-request layout

Problem

There is no public Extension API to query whether the sidebar, panel (bottom), or auxiliary bar are currently visible. The internal IWorkbenchLayoutService has exactly what's needed — isVisible("workbench.parts.sidebar") and onDidChangePartVisibility — but neither is bridged to the extension host.

As a result, extensions that need to save and restore layout state (e.g. a "maximize editor" toggle) have no reliable way to read the current visibility of these three parts. The only workaround is to parse VS Code's internal SQLite database (state.vscdb) directly, which is fragile and reads stale data mid-session.

The layout buttons in the VS Code title bar already track this state correctly because they run in the renderer process with direct access to the layout service. Extensions cannot do the same.

Proposed API

Add to vscode.window:

/**
 * Whether the primary sidebar is currently visible.
 */
readonly isSideBarVisible: boolean;

/**
 * Whether the bottom panel is currently visible.
 */
readonly isPanelVisible: boolean;

/**
 * Whether the auxiliary bar (secondary sidebar) is currently visible.
 */
readonly isAuxiliaryBarVisible: boolean;

/**
 * Fired when the visibility of the sidebar, panel, or auxiliary bar changes.
 */
readonly onDidChangeLayoutVisibility: Event<{
  sideBar: boolean;
  panel: boolean;
  auxiliaryBar: boolean;
}>;

Use Case

A "maximize editor" extension needs to:

  1. Read current visibility of all three parts before hiding them
  2. Restore only the parts that were originally visible

Without this API, if the user hides the bottom panel manually before pressing maximize, the extension has no way to know — and incorrectly restores it on unmaximize.

This is a general-purpose API gap: any extension that interacts with workbench layout (focus modes, presentation modes, Zen-like toggles) hits the same wall.

Current Workaround (and why it's bad)

Read ~/.config/Code/User/workspaceStorage/<hash>/state.vscdb directly via a custom SQLite B-tree parser. Problems:

  • Only accurate at window open (VS Code flushes the DB on close, not on toggle)
  • Relies on undocumented internal key names (workbench.sideBar.hidden, etc.)
  • Breaks if VS Code changes its storage format

Prior Art

  • Context keys sideBarVisible, panelVisible, auxiliaryBarVisible already exist internally and are kept in sync via onDidChangePartVisibility
  • These are used in when clauses in package.json but cannot be read at runtime by extension code
  • Exposing them (or wrapping isVisible()) would be a small bridge with high utility
Dominant language
TypeScript
Stars
193k
Forks
42.9k
PR metrics pending

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/vscode

All issues in microsoft/vscode

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.