Workspace-style tabs with multiple terminal sessions inside one project tab

[jimmyn]

Summary

Workspace-style project tabs should support multiple independent terminal sessions inside one top-level tab (for example: Claude Code + local server + extra shell).

Problem

I want one top-level tab to behave like a project workspace and keep all related sessions grouped together. In agentic coding workflows, this commonly means running an agent in one session and local runtime/development commands in additional sessions in the same workspace. The current model does not provide a true workspace-with-internal-sessions/sub-tabs flow for this use case.

Reproduction steps or desired workflow

1. Open a project as a single top-level tab/workspace.
2. Start Claude Code (or another CLI agent) in one terminal session inside that workspace.
3. Open a second terminal session in the same workspace to run a local server.
4. Optionally open a third+ terminal session for tests/logs/other commands.
5. Switch among these sessions within the same workspace context without splitting the project across multiple top-level tabs.

Artifacts

Warp version

v0.2026.04.27.15.32.stable_02

Operating system

macOS

[oz-for-oss]

@Manoj7ar

I reviewed the previous comment and agree with the framing: this is not primarily a pane-layout request. Warp can already host multiple sessions in one top-level tab via split panes and tab configs, but the requested behavior is a workspace-scoped session switcher where related terminal/agent sessions stay grouped under one project tab without all being visible at once.

Implementation should start with product/design mocks before code: define the internal session-strip UX, keyboard switching, close/rename/reopen behavior, how a session can be promoted into a split, and how this interacts with vertical tabs and saved tab configs. This should stay under needs-mocks for now rather than ready-to-implement.

Reasoning

Maintainer-facing notes:

• Existing tab structure: TabData holds a ViewHandle<PaneGroup> (app/src/tab.rs:135), so a top-level tab already owns a group of pane/session state rather than a single PTY. Window persistence stores WindowSnapshot.tabs: Vec<TabSnapshot> and each tab stores a PaneNodeSnapshot root (app/src/app_state.rs:44, app/src/app_state.rs:62).
• Existing pane/session model: PaneGroup owns PaneData plus pane_contents: HashMap<PaneId, Box<dyn AnyPaneContent>> (app/src/pane_group/mod.rs:827). PaneData is a split tree of PaneNode::Branch/PaneNode::Leaf and filters hidden panes via visible_pane_ids() (app/src/pane_group/tree.rs:44, app/src/pane_group/tree.rs:472). User-created sessions today are visible panes; hidden panes exist for implementation-specific cases such as move/job/closed/temporary replacement/child-agent, not a general user-facing session stack (app/src/pane_group/tree.rs:55).
• Existing navigation/UI: vertical tabs already has a setting-level distinction between displaying every pane and displaying one tab row. VerticalTabsDisplayGranularity::{Panes,Tabs} is persisted in settings (app/src/workspace/tab_settings.rs:330), and pane_ids_for_display_granularity renders either all visible panes or only the focused pane (app/src/workspace/view/vertical_tabs.rs:5033). Summary mode also exists behind VerticalTabsSummaryMode, but none of these creates internal session tabs; they summarize or navigate the current split-pane tree.
• Existing automation/workaround: tab configs can open multiple terminal, agent, or cloud panes and commands in one top-level tab (app/src/tab_configs/tab_config.rs:99, resources/bundled/skills/tab-configs/SKILL.md). This is useful for launch layouts, but it still creates split-pane layouts rather than switchable hidden/internal sessions.

Likely implementation direction:

1. Product/design first: this needs mocks for the internal session strip, empty/new-session affordance, session titles/status indicators, and interactions with vertical tabs. The existing needs-mocks label is appropriate.
2. Reuse PaneGroup/PaneId/TerminalPane as much as possible rather than inventing a separate PTY store. The new abstraction likely belongs above or beside PaneData: either a user-visible session stack within a PaneGroup, or a new SessionGroup that can contain one or more visible PaneData layouts plus inactive session leaves.
3. Preserve split panes as the side-by-side mode. The requested “promote to split” behavior can be modeled as moving a session from the inactive/internal group into the visible PaneData tree. The reverse operation needs a product decision.
4. Persistence and restoration must be designed up front because TabSnapshot.root currently represents the tab’s visible pane tree. A stacked/session-group model will likely require new snapshot data for inactive internal sessions, migration/default behavior for existing tabs, and decisions about undo-close/reopen behavior.
5. Tab configs should probably grow a session-group representation only after the product model is settled; today their schema is pane-tree-only.

Duplicate check against the provided open/recent issues did not find a likely duplicate. The closest issues are different surfaces: #9539 is a vertical-tabs settings popup click bug, #9550 is external editor state for CLI agents, #9545 is drag-and-drop image handling for CLI agents, and #9525 is stale tab title text for Claude Code.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[jimmyn]

1. Ideally one side tab should have a workspace like horizonal tabs like it is done in cmux for example

2. Third-party CLI agents like Claude Code, Warp Agent/Oz, local shell/server sessions, cloud agents, or all of these

[jimmyn]

@oz-agent did you check my last reply?

[Manoj7ar]

@oz-agent I think the key distinction here is that this is not a pane-layout request, it’s a workspace session model request.

Current primitives in Warp:

• top-level tabs = project/context containers
• split panes = simultaneous visible processes
• vertical tabs = navigation surface

What’s missing is:

workspace-scoped session groups

Meaning:

Project A (top-level tab)
├── Claude Code
├── Local dev server
├── Test runner
└── Logs shell

with internal session switching (cmux-style), instead of:

• opening separate top-level tabs (context fragmentation), or
• keeping everything in visible splits (screen-space pressure).

Why this matters for agent workflows:

Agents increasingly need companion processes:

• local app server
• test watcher
• logs
• scratch shell

Those are part of the same working context but different runtime sessions.

A useful implementation shape could be:

• WorkspaceTab

  • owns project root + file tree + context

• SessionGroup

  • owns multiple PTYs/agent sessions

• internal tab strip for session switching

• optional “promote to split” for side-by-side workflows

That keeps the project as the unit of organization, while sessions become internal runtime units.

Feels especially aligned with Warp’s move toward agent-native workflows.

[tokezooo]

Yes please, much needed feature