[Feature]: Close the active right-panel tab with Cmd+W

[caezium]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/web

Problem or use case

When keyboard focus is inside a Files, Diff, Browser, Plan, or Terminal surface in the right panel, pressing Cmd+W closes the T3 Code app window instead of closing the active panel tab.

T3 Code already binds mod+w to close a focused terminal, but there is no corresponding command or focus context for non-terminal right-panel surfaces. This is surprising for a tabbed interface and makes a common tab-closing shortcut destructive.

Proposed solution

Add a configurable rightPanel.closeActiveSurface command with a default mod+w binding gated by right-panel focus.

• Close only the active right-panel surface.
• Reuse the existing surface cleanup path so Browser and Terminal resources are disposed correctly.
• If another surface remains, activate the existing fallback surface.
• If the last surface closes, close the panel as it does today.
• Preserve the native window-close behavior when the right panel does not own focus.
• Ensure embedded Browser surfaces forward the shortcut to the app consistently.

Why this matters

Cmd+W is a standard close-tab shortcut. Applying it to the focused panel tab prevents accidental app-window closure and makes right-panel tabs behave consistently with terminal tabs and other desktop tabbed interfaces.

Smallest useful scope

Introduce one keybinding command and a right-panel focus context, then route it to the existing active-surface close callback. No new panel state, confirmation dialog, or queue of close actions.

Alternatives considered

• Add a hard-coded keydown listener in the tab component. This bypasses T3 Code's configurable keybinding system and creates conflicts with the existing terminal binding.
• Always intercept Cmd+W whenever the panel is visible. That would close a panel tab even when the user is actively typing in the chat composer.
• Keep native window close behavior. This remains surprising and risks losing the user's current window layout.

Risks or tradeoffs

• Focus detection must distinguish the right-panel terminal from the bottom terminal drawer.
• The new binding overlaps terminal.close; right-panel focus must take precedence for a terminal hosted as a panel surface while drawer terminals keep their current behavior.
• Electron's native close accelerator and embedded Browser shortcut forwarding need to respect the renderer's handled state.

Examples or references

Related discoverability issue: #4146.

Contribution

• I would be open to helping implement this.

[juliusmarminge]

PR #4148 has been refreshed without opening a new PR: branch codex/refresh-pr-4148 at commit 137c50175e. The Cmd+W right-panel behavior and review follow-ups passed 123 focused tests plus real-app before/after verification. Status remains 🚧 In Progress until merge.

[shkumbinhasani]

Follow-up now that this shipped: Cmd+W still closes the whole window on macOS when no right-panel tab or terminal is focused, which is the state you are in during a normal chat.

The handler in apps/web/src/components/ChatView.tsx (rightPanel.close) returns early when activeRightPanelSurface is unset, and the comment says this is so the shortcut keeps its native close-window meaning. In practice that makes Cmd+W a tab-close shortcut when a panel is open and a window-close shortcut when it is not, so muscle memory from closing panel tabs in a row ends with the window gone.

Threads already behave like tabs: they sit in a list, Cmd+1..9 jumps between them, Cmd+Shift+[ and ] cycle them. Every tabbed Mac app (Safari, Chrome, VS Code, iTerm, Finder) closes the current tab on Cmd+W and only closes the window when the last tab goes.

Proposal:

1. When a panel tab or terminal is focused, keep the current behavior.
2. Otherwise, Cmd+W settles (or closes) the active thread, the same action as Cmd+Shift+S today.
3. Only fall through to the native close-window when there is no thread to settle, or make that fallback a setting.

Related: #10161 covers the Windows side where the same fall-through quits the app.