[FEATURE] SSH sessions should have feature parity with local sessions (Terminal & Preview panes missing)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

After the April 2026 desktop redesign, local sessions gained a polished set of panes — Preview, Diff, Terminal, Tasks, and Plans. The redesign blog post explicitly framed this as achieving "parity" with the CLI experience.

However, SSH sessions receive a reduced subset of this UI. The pane menu in an SSH session only exposes Diff, Tasks, and Plans. Terminal and Preview are silently omitted — there is no tooltip, no "coming soon" label, no documented rationale.

Side-by-side comparison

Local session (5 panes):

• ▷ Preview (⇧⌘P)
• ▭ Diff (⇧⌘D)
• >_ Terminal (⌃`)
• ▦ Tasks
• ☰ Plans

SSH session (3 panes):

• ▭ Diff (⇧⌘D)
• ▦ Tasks
• ☰ Plans

(screenshots attached in Additional Context)

SSH is the primary workflow for users whose codebase lives on a company dev server, a lab machine, or a VPS. For these users, "local" is literally not an option — the SSH experience is the product.

The missing Terminal breaks the fundamental agentic coding loop: see Claude's edit → run a test/build → iterate. Without an integrated terminal, users must keep a separate terminal emulator open and manually sync its working directory and environment with Claude's session. This is precisely the context-switch the redesign was supposed to eliminate.

Proposed Solution

Bring SSH sessions to feature parity with local sessions:

• [ ] Expose the Terminal pane in SSH sessions, spawning bash -i (or the user's login shell) on the remote host, inheriting the session's working directory and environment.
• [ ] Expose the Preview pane in SSH sessions via automatic local port forwarding for dev servers running on the remote (same approach as VS Code Remote-SSH).
• [ ] If any pane genuinely cannot be supported over SSH in the short term, show it in the menu with an explanation or "coming soon" affordance instead of hiding it silently.

Why this is technically feasible

The infrastructure already exists:

1. A bidirectional pipe to the remote host is already established. The desktop app deploys ccd-cli to ~/.claude/remote/ccd-cli/<version> on the remote and streams JSON over stdio. That's the hard part — it's done.
2. File I/O over that pipe already works — the File pane reads/writes remote files fine. This proves the transport layer is not the limitation.
3. Arbitrary shell execution already works — Claude runs bash commands on the remote via tool calls. A Terminal pane is essentially bash -i over the same pipe exposed via an xterm.js-style frontend. No new protocol required.
4. Preview via port forwarding is a standard SSH feature that IDEs like VS Code Remote-SSH already negotiate automatically.

The Terminal pane in an SSH session is primarily a UI-wiring task, not a systems-level undertaking.

Alternative Solutions

• Keep an external terminal emulator open manually. Works, but this is exactly the context-switch the redesign eliminated for local users. The terminal's working directory and environment also drift from Claude's session over time.
• Use tmux/mosh in a separate window. Same problem plus extra setup burden. Does not integrate with the session's diff/file/plan panes.
• Run the desktop app on the remote via X-forwarding/VNC. Not practical — the remote is often headless, and the desktop app is not available for all Linux distributions.

Priority

Critical - Blocking my work

Feature Category

Other

Use Case Example

1. Connect to a remote dev server via SSH session in Claude Code Desktop
2. Ask Claude to implement a feature — it edits files on the remote host
3. Want to run pytest or cargo test to verify the change
4. Current experience: Must alt-tab to a separate terminal, manually cd to the project directory, re-export environment variables, run the test, come back to Claude
5. Working directory and shell environment gradually drift from Claude's session as the conversation progresses
6. With integrated Terminal pane: The full edit → test → iterate loop happens in one window, same as local sessions today

Additional Context

Environment

• Claude Desktop: v1.2773.0 (884b37), 2026-04-15
• Host OS: macOS
• Remote: Linux (ccd-cli 2.1.101)
• Plan: Max

Screenshots — pane menu comparison

SSH session (3 panes):

(see attached: ssh-panes.png)

Local session (5 panes):

(see attached: local-panes.png)

Related issues

• #26694 — SSH remote host: macOS/darwin support
• #15208 — SSH connector for Claude Code Web
• #37345 — CLI-as-remote-control-client
• #46845 — SSH first-run ccd-cli crash

These all point to the same theme: the SSH workflow matters to a meaningful slice of users and is currently a second-class citizen in the desktop app.