spec: hide Warp from Dock on macOS by oz-for-oss[bot] · Pull Request #9349 · warpdotdev/warp

oz-for-oss · 2026-04-29T00:41:32Z

Summary

Adds a product spec for a macOS setting that hides Warp from the Dock and Command-Tab app switcher while showing a status-bar fallback.
Adds a technical spec grounded in the current hotkey window, settings, macOS AppKit, menu, and startup restoration code paths.
Calls out optional feature-flag/PR splitting for the native macOS presentation changes.

Related issue: #1154

Validation

Spec-only change.
Researched relevant Warp settings, hotkey window, macOS platform, menu, and startup restoration code paths before drafting.
Reviewed generated spec files for required scope and output paths.

oz-for-oss · 2026-04-29T00:42:35Z

@oz-for-oss[bot]

I'm starting a first review of this spec-only pull request.

You can follow along in the session on Warp.

I completed the review and posted feedback on this pull request.

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

I completed the review and posted feedback on this pull request.

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

oz-for-oss

Overview

This PR adds product and technical specs for a macOS-only, opt-in setting that hides Warp from the Dock while the dedicated Hotkey window workflow is active. The specs define default behavior, recovery safeguards, platform API work, settings/UI integration, telemetry constraints, and validation coverage.

Concerns

No blocking concerns found. The open UX choices are explicitly bounded, and the technical spec provides feasible implementation paths consistent with the referenced settings, hotkey, and macOS platform layers.

Verdict

Found: 0 critical, 0 important, 0 suggestions

Approve

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

oz-for-oss

Overview

This PR adds product and technical specs for a macOS-only opt-in setting that hides Warp from the Dock when the dedicated Hotkey window workflow is enabled.

Concerns

The recovery safeguard is based on a configured keybinding, but the current global shortcut registration path can fail without surfacing success to the proposed effective-state logic; the spec should require a successful registration or a visible-Dock fallback.
The product spec still leaves persistence/sync scope as an open question even though the behavior and tech spec assume storage with existing dedicated Hotkey window settings.

Verdict

Found: 0 critical, 2 important, 0 suggestions

Request changes

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

oz-for-oss · 2026-04-29T00:45:40Z

+7. Warp disappears from the Dock but remains running and responding to the registered global hotkey.
+8. If the user disables the setting, clears the keybinding, or changes global hotkey mode, the same effective-state code restores regular activation policy and the Dock icon returns.
+## Risks and mitigations
+1. Risk: Users can lose their obvious app entry point if the Dock icon is hidden without a working hotkey. Mitigation: effective Dock hiding requires a configured dedicated Hotkey window keybinding and restores the Dock icon when the keybinding is removed.


⚠️ [IMPORTANT] Configured keybinding is not enough for recovery: global shortcut registration can fail without a success signal to this effective-state logic, so this mitigation can still hide the Dock icon with no usable hotkey. Require successful registration or an immediate Dock-visible fallback when registration fails.

oz-for-oss · 2026-04-29T00:45:40Z

+2. Validate that non-macOS builds ignore the setting and do not expose macOS-specific UI.
+3. Validate that settings persistence and restart behavior match the effective-state rules in Behavior 8 through 12.
+## Open questions
+1. Should this setting be stored only locally on each machine, or should it sync with the existing dedicated Hotkey window settings? The current product expectation is that it persists with the dedicated Hotkey window settings, while non-macOS clients ignore it.


⚠️ [IMPORTANT] This remains an open question while Behavior 12 and the tech spec require persistence with existing dedicated-window settings. Resolve whether the preference syncs or stays local before implementation so settings storage, UI indicators, and non-macOS ignore behavior are consistent.

ShankyJS · 2026-04-29T06:25:10Z

I have reviewed this spec with the help of two different models Opus 4.7 and Codex; both agree that this spec looks to be promising to fix the issue.

If anybody else with experience on the repo could double check, I'd be comfortable taking a stab at implementation now.

As per Claude's:

Accurate:
  - app/src/settings/mod.rs GlobalHotkeyMode (line 258) and QuakeModeSettings (line 328) exist as described, with the exact dropdown labels.
  - app/src/terminal/keys_settings.rs toml paths (global_hotkey.dedicated_window.settings, .enabled, global_hotkey.toggle_all_windows.*) match exactly. Existing helpers like
  set_quake_mode_keybinding_and_write_to_user_defaults follow the naming pattern the spec proposes.
  - crates/warpui/src/platform/mac/objc/{app.m,window.m} and features_page.rs exist.
  - Mutual exclusion of Quake / activation hotkey is real (line 81-90).

  Solid design choices:
  - Effective-state helper that defaults to "visible" on non-mac/missing keybinding is the right safety posture.
  - Setting persisted in QuakeModeSettings (synced) but gated by macOS-only effective state — matches existing SupportedPlatforms::DESKTOP + sync model.
  - NSApplicationActivationPolicyAccessory is the correct AppKit API for this. Note: it does remove the app from Cmd-Tab — spec acknowledges this in product copy (good).

  Minor gaps to flag:
  1. Line ranges are precise (e.g. mod.rs (239-276)) but the AI cited some that drift slightly from current master — review the actual lines, not the numbers, when implementing.
  2. Spec says "add helper or call from Rust" for the activation policy — worth picking one before splitting agents; mixing both creates merge conflicts.
  3. Open question #2 (disable switch vs. allow-but-inactive when keybinding missing) should be resolved before UI work starts.

  Overall: the spec is realistic, the codebase anchors check out, and the recovery safeguards (auto-restore on mode change / cleared keybinding) address the main "user gets locked out" risk. Safe to proceed.

Co-Authored-By: Oz <[email protected]> Co-Authored-By: Jhan Silva <[email protected]>

cla-bot Bot added the cla-signed label Apr 29, 2026

oz-for-oss Bot mentioned this pull request Apr 29, 2026

Hide Warp icon from the Dock when using Hotkey window #1154

Open

oz-for-oss Bot commented Apr 29, 2026

View reviewed changes

ShankyJS mentioned this pull request May 2, 2026

Hide Dock icon when using dedicated hotkey window (GH-1154) #9926

Open

1 task

oz-by-warp Bot force-pushed the oz-agent/spec-issue-1154 branch from 9a033bd to b5ae010 Compare May 6, 2026 01:16

oz-for-oss Bot changed the title ~~spec: hide Warp icon from the Dock when using Hotkey window~~ spec: hide Warp from Dock on macOS May 6, 2026

spec: add Dock visibility specs

d3ce5e7

Co-Authored-By: Oz <[email protected]> Co-Authored-By: Jhan Silva <[email protected]>

oz-by-warp Bot force-pushed the oz-agent/spec-issue-1154 branch from b5ae010 to d3ce5e7 Compare May 6, 2026 15:59

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

spec: hide Warp from Dock on macOS#9349

spec: hide Warp from Dock on macOS#9349
oz-for-oss[bot] wants to merge 1 commit intomasterfrom
oz-agent/spec-issue-1154

oz-for-oss Bot commented Apr 29, 2026 •

edited

Loading

Uh oh!

oz-for-oss Bot commented Apr 29, 2026 •

edited

Loading

Uh oh!

oz-for-oss Bot left a comment

Uh oh!

oz-for-oss Bot left a comment

Uh oh!

oz-for-oss Bot Apr 29, 2026

Uh oh!

oz-for-oss Bot Apr 29, 2026

Uh oh!

ShankyJS commented Apr 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

oz-for-oss Bot commented Apr 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Validation

Uh oh!

oz-for-oss Bot commented Apr 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

oz-for-oss Bot left a comment

Choose a reason for hiding this comment

Overview

Concerns

Verdict

Uh oh!

oz-for-oss Bot left a comment

Choose a reason for hiding this comment

Overview

Concerns

Verdict

Uh oh!

oz-for-oss Bot Apr 29, 2026

Choose a reason for hiding this comment

Uh oh!

oz-for-oss Bot Apr 29, 2026

Choose a reason for hiding this comment

Uh oh!

ShankyJS commented Apr 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

oz-for-oss Bot commented Apr 29, 2026 •

edited

Loading

oz-for-oss Bot commented Apr 29, 2026 •

edited

Loading