Independent zoom level per OS window (Cmd +/-/0 affects focused window only)

[Eridanus117]

Pre-submit Checks

• I have searched Warp feature requests and identified several related but non-matching issues — see Relation to existing issues below.
• I have searched Warp docs and this is not configurable today.

Describe the solution you'd like?

Cmd + / Cmd - / Cmd 0 should adjust the focused OS window's zoom level only, leaving other Warp windows at their existing zoom. All tabs and splits inside the same window share that window's zoom level (a window-scoped baseline, not per-pane override).

In-memory only is acceptable (zoom resets to global default on app restart) — same trade-off PR #9705 makes for per-pane font size.

Is your feature request related to a problem? Please describe.

I run multiple OS-level Warp windows across monitors of different sizes and viewing distances (e.g. a small reference window on a side monitor, a primary window on the main display). I want each window at its own readable zoom. Today Cmd +/- is global — adjusting one window changes all of them, which is the opposite of what I want.

VS Code, iTerm2, Chrome, and most macOS apps with multi-window support behave this way already.

Relation to existing issues (please review before triage)

I went through the zoom/font-size cluster carefully. None of the existing issues cleanly match a per-OS-window zoom baseline:

• Different font size per window/split/tab #1394 "Different font size per window/split/tab" — closest match in title, but the scope bundles three independent design decisions (window vs split vs tab) and has been stuck at triaged for ~4 years. The window-level slice alone is the smallest meaningful step.
• Allow for per window font size #6739 "Allow for per window font size" / PR feat: per-pane monospace font size #9705 — title says "window" but the body describes splitting into "4 windows two on top and two on bottom," i.e. panes, not OS windows. PR feat: per-pane monospace font size #9705 correctly implements per-pane in-memory override. That's an orthogonal feature (pane override on top of a baseline), not a substitute for a window-scoped baseline.
• Isolate zoom levels per pane / tab #2573 "Isolate zoom levels per pane / tab" (ai:ready-to-spec) — covers pane/tab isolation but does not include the window dimension.
• Support setting unique font sizes per pane #1439 per-pane font size — different layer.

Architecture note

Currently ZoomLevel is a global SettingsBackedValue. This proposal moves the owner from global to WindowState (with global as the default for new windows). PR #9705's per-pane override would naturally layer on top: effective_zoom = pane_override ?? window_zoom ?? global_default.

Question for @oz-agent

Given the above mapping, is the cleanest path:

(a) Reuse #1394 by narrowing its scope to "window only" (and closing this issue as dup), letting the split/tab variants live in #1439 / #6739 / #2573?
(b) Keep this issue as the canonical "per-OS-window zoom baseline" tracker, leaving #1394 as a meta/umbrella?
(c) Something else?

I am happy to follow your routing recommendation.

cc @oss-maintainers for human-side visibility.

Operating system (OS)

macOS

How important is this feature to you?

3

[oz-for-oss]

@Eridanus117

This issue appears to overlap with existing issues:

• Different font size per window/split/tab #1394 — Different font size per window/split/tab
• Allow for per window font size #6739 — Allow for per window font size

If this report is meaningfully different, please comment with the additional context or distinguishing behavior so a maintainer can review it. Otherwise, a maintainer may close it as a duplicate after review.

Maintainer details

I concluded that feature request for per-OS-window zoom/size isolation; current code keeps zoom as a settings-backed app-wide value and two existing open issues already request the same per-window shortcut/settings behavior..

Duplicate reasoning

• Different font size per window/split/tab #1394: It describes Cmd +/- size changes being synchronized across Warp windows and asks for separate per-window sizing, which overlaps with this request's focused-window-only zoom behavior.
• Allow for per window font size #6739: It asks for Cmd + / Cmd - or settings changes to shrink one Warp window while leaving other windows unchanged, matching the requested per-OS-window baseline behavior.

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

Powered by Oz

[Eridanus117]

Thanks @oz-for-oss for the quick triage. I want to surface a fact the dup analysis missed:

PR #9705 (which would close #6739) implements a per-pane override, not a per-OS-window baseline. The storage is HashMap<PaneId, f32> on PaneGroupFocusState (app/src/pane_group/focus_state.rs), and the resolver is pane_override.unwrap_or_else(global) — no window-scoped layer in between. PR self-confirms: "Per-pane override is dropped when a pane is dragged to another window — the destination group starts at the global default."

Concretely, after PR #9705 ships:

• Open Window A, Cmd + to 18pt → only the focused pane in A goes to 18pt.
• Open a new tab in Window A → new tab's pane uses the global default (e.g. 14pt), not Window A's 18pt.
• Split Window A → new pane uses the global default, not 18pt.
• Restart Warp → all overrides gone (PaneId is in-memory only, by design).

That's the right design for #6739's body use case (multiple panes in one terminal at different sizes for monitoring varied output). It does not give a per-OS-window zoom baseline that all tabs/splits inside that window inherit.

The two requests are layered, not redundant: effective_zoom = pane_override (PR #9705) ?? window_zoom (this issue) ?? global_default. Adding the window layer requires no change to PR #9705 — the unwrap_or_else(global) call site simply consults a window-scoped value before falling through.

Happy to follow whatever routing makes sense (this issue, narrowing #1394, or something else). But the dup verdict against #6739 is based on title-level matching that misses the implementation scope. cc @oss-maintainers.

[Eridanus117]

@oz-agent — could you re-review with the per-pane vs per-OS-window architectural distinction surfaced above? Specifically: given that PR #9705 implements HashMap<PaneId, f32> (no window-scoped layer), is the cleanest routing (a) narrowing #1394 to "window only" and closing this as cross-link, or (b) keeping this issue as the canonical per-OS-window-baseline tracker, with #1394 retained as a meta/umbrella for the broader window/split/tab cluster?

[oz-for-oss]

@Eridanus117

Re-reviewing with the per-pane vs per-OS-window distinction: PR #9705 is pane-scoped and should not be treated as satisfying a per-OS-window zoom baseline.

My routing recommendation is (a): use #1394 as the canonical tracker for the OS-window baseline, add a maintainer note/narrowing there that its actionable scope is "window only", and keep pane/tab variants in #1439 / #2573 / #6739 / PR #9705. This issue can be closed as a cross-linked duplicate of #1394, with the architecture note here linked from #1394 because it captures the layering clearly.

I would not route this as "covered by #6739 / PR #9705"; that path is focused-pane font-size override behavior, not a window baseline inherited by new tabs and splits in the same OS window.

Reasoning

This run was triggered by an @oz-agent follow-up on an already-triaged issue, so response mode is appropriate and no label changes should be applied.

Duplicate/routing check: I enumerated all open issues with gh api --paginate /repos/warpdotdev/warp/issues?state=open&per_page=100, excluding PRs and #10115, and filtered the paginated snapshot for zoom/font-size/window/pane/tab candidates. The relevant open candidates were #1394, #6739, #2573, #1439, #8444, and #5185. #1394 is the best canonical issue because its body explicitly says current Cmd +/- font-size adjustment is synchronized across all Warp windows/splits/tabs and asks to adjust font sizes for each window separately. #2573, #1439, #8444, and #5185 are pane/tab/panel-level. #6739 has title/solution wording that overlaps with a single-window request, but its scenario and PR #9705 are pane-focused, so it is not the right canonical tracker for an OS-window baseline.

Code/implementation check: app/src/window_settings.rs:73 defines zoom_level: ZoomLevel as part of WindowSettings; app/src/workspace/view.rs:15555 and app/src/workspace/view.rs:15563 reset/adjust zoom by updating WindowSettings::handle(ctx).zoom_level; app/src/settings_view/appearance_page.rs:914 handles WindowSettingsChangedEvent::ZoomLevel and calls ctx.set_zoom_factor(...); crates/warpui_core/src/core/app.rs:1188 stores the zoom factor on AppContext and invalidates all views. That supports the reporter's claim that current zoom ownership is app/global rather than per OS window.

PR #9705 metadata confirms the distinction: its description says it adds independent monospace font-size control for each terminal pane, stores overrides as HashMap<PaneId, f32> on PaneGroupFocusState, and keeps the override in memory only. It also calls out focused-pane shortcut behavior and a limitation when a pane is moved to another window. Therefore #9705 is compatible with a future layering model like pane_override ?? window_zoom ?? global_default, but it does not itself provide the window-scoped baseline requested here.

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

Powered by Oz

[Eridanus117]

Following @oz-agent's recommendation (a). Posted the narrowing-scope argument at #1394 (#1394 (comment)).

Happy for a maintainer to close this as a cross-linked duplicate of #1394 once the architecture note here has been mirrored over — or to keep it open as a thin tracker for the per-OS-window slice if that turns out cleaner. Either routing works for me.

[oz-for-oss]

@Eridanus117

I agree with routing (a): use #1394 as the canonical tracker for the per-OS-window zoom/font-size baseline, and close this issue as a cross-linked duplicate now that the architecture note has been mirrored there.

The pane/tab work should stay separate: #6739 / PR #9705 and #1439 cover per-pane font-size overrides, while #2573 covers pane/tab zoom isolation. Those are layered under a window baseline rather than substitutes for it.

Reasoning

This run was triggered by an @oz-agent follow-up on an already triaged issue, so response mode is appropriate and no labels should be changed by the workflow. I enumerated all open issues via gh api --paginate repos/warpdotdev/warp/issues?state=open&per_page=100, excluding PRs and #10115, then filtered the full local result set for zoom/font/window candidates. The closest candidates are #1394 and #6739; #2573, #1439, #8444, and #5185 are related but scoped to pane/tab/panel behavior rather than an OS-window baseline. #1394's body already describes Cmd +/- font sizing being synchronized across Warp windows/splits/tabs and asks for separate sizes per window; the reporter's 2026-05-05 comment on #1394 mirrors the #10115 architecture note and narrows the actionable slice to window-only. #6739's title/body are close, but PR #9705 (feat: per-pane monospace font size) explicitly implements per-pane behavior, stores overrides as HashMap<PaneId, f32> on PaneGroupFocusState, and documents an in-memory per-pane limitation when panes move between windows, so it should not be treated as the OS-window-baseline canonical tracker. Current code also supports the distinction: app/src/window_settings.rs:73 defines WindowSettings.zoom_level; app/src/workspace/view.rs:15555-15577 changes that setting for zoom shortcuts; app/src/settings_view/appearance_page.rs:915-925 reacts to ZoomLevel changes by calling ctx.set_zoom_factor; and crates/warpui_core/src/core/app.rs:1188 applies a single app-wide zoom factor and invalidates all views. That makes the current behavior global and leaves #1394 as the best existing canonical issue once narrowed to the per-OS-window baseline.

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

Powered by Oz