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:
- Read current visibility of all three parts before hiding them
- 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
Problem
There is no public Extension API to query whether the sidebar, panel (bottom), or auxiliary bar are currently visible. The internal
IWorkbenchLayoutServicehas exactly what's needed —isVisible("workbench.parts.sidebar")andonDidChangePartVisibility— 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:Use Case
A "maximize editor" extension needs to:
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.vscdbdirectly via a custom SQLite B-tree parser. Problems:workbench.sideBar.hidden, etc.)Prior Art
sideBarVisible,panelVisible,auxiliaryBarVisiblealready exist internally and are kept in sync viaonDidChangePartVisibilitywhenclauses inpackage.jsonbut cannot be read at runtime by extension codeisVisible()) would be a small bridge with high utility