[BUG] [Desktop / macOS] 'Open in → New Window' detached session: font renders smaller than main, no per-window controls, Cmd+/Cmd- keystrokes routed to main window instead

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (searched for "new window font size", "open in new window font", "desktop font size", "zoom shortcut new window", "detached session window", "cmd plus cmd minus" — no matches)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code (Desktop 1.9255.2)

What's Wrong?

On the Claude Desktop app for macOS, opening a session via Open in → New Window (from a session's context menu / "Open in" submenu) creates a detached window that does not behave as an independent window:

1. The new window renders text at a smaller font size than the main app window.

Side-by-side, the same conversation rendered in the main window and the detached window shows visibly smaller text in the detached window. The detached window is not respecting whatever font-size setting governs the main window (whether default or user-modified).

2. The new window has no font-size controls of its own.

There's no per-window font setting accessible from the detached window (no settings/preferences entry, no view menu zoom). The window's font size appears hardcoded to a default that's smaller than the main app's effective size.

**3. Cmd+ / Cmd- keyboard shortcuts pressed inside the detached window are routed to the main window, not the focused window.**

While the detached "Open in New Window" session is focused, pressing Cmd+ or Cmd- (zoom in / zoom out) leaves the detached window unchanged and instead changes the font size of the main app window (which may not even be visible / may be on a different display). The keystroke is firing the action but targeting the wrong window. This is the most jarring symptom: the user has to click the main window to get visual feedback on what their keypress did, then click back.

Likely common cause

All three symptoms point to the detached window not being a fully-instantiated app instance — it appears to share preferences/key-handling with the main window rather than owning its own. Either:

• Detached windows aren't reading the active font-size preference at creation, or
• The font-size preference is single-instance on the main window and detached windows have no way to read or set it, or
• Both windows share one preference, but key events from detached windows are misrouted to the main window's event handler.

Steps to Reproduce

1. Launch Claude Desktop (1.9255.2 on macOS 26.5).
2. In the main window, increase font size with Cmd+ until text is visibly larger than default.
3. Open any session's "Open in" submenu and choose New Window.
4. Compare text rendering between the two windows — detached is smaller.
5. With the detached window focused, press Cmd+ or Cmd-.
6. Observe: detached window is unchanged. Switch to the main window — its font has changed instead.

What Should Happen?

| Observed | Expected |
|---|---|
| Detached window renders smaller font than main | Detached window renders at the same effective font size as the main window |
| No font controls in detached window | Detached window has its own font controls (or inherits the global one consistently) |
| Cmd+/Cmd- in detached window changes the main window's font | Keyboard shortcuts in a focused window affect that window |

Environment

| Field | Value |
|---|---|
| Claude Desktop version | 1.9255.2 |
| Platform | macOS 26.5 (build 25F71, "Tahoe") |
| Display config | Multi-monitor (issue observed across monitors but not display-dependent) |

Severity

Medium. Workaround is to do everything in the main window or repeatedly cross-check which window the keypress hit. But the routing issue (#3) is genuinely surprising — keypresses in window A affecting window B is a violation of basic windowing expectations and could lead users to think their keyboard shortcut isn't working at all when in fact it's working invisibly on another monitor.