Fix empty SwiftUI Settings window - #3056
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. |
clawsweeper
Bot
added
P1
|
Codex review: needs maintainer review before merge. Reviewed August 18, 2026, 5:30 PM ET / 21:30 UTC. ClawSweeper reviewWhat this changesThe branch declines untitled document windows for the menu bar app and closes restored empty SwiftUI Settings placeholders, with focused AppKit tests. Regression provenancePossible regression — probable (reproduction; reviewed change; known regression link). No predecessor PR is attributed. Merge readinessKeep open. Current main still has the empty SwiftUI Settings scene, while this focused patch prevents its launch-time presentation and preserves the real AppKit Settings window. Priority: P1 Review scores
Verification
Live VerificationCommand: Result: FAIL (failed) — execution before step 1 Assertions:
How this fits togetherCodexBar uses SwiftUI for application scenes and commands, while an AppKit controller owns the real preferences window. Launch and restoration events enter through the app delegate and should result in no blank window or the retained AppKit Settings window. flowchart LR
A[macOS launch or reopen] --> B[App delegate]
B --> C[Untitled window policy]
B --> D[Restored window events]
C --> E[SwiftUI Settings placeholder]
D --> F[Placeholder window guard]
E --> F
F --> G[AppKit Settings window]
F --> H[No blank launch window]
Before merge
Agent review detailsSecurityNone. Review metrics
Root-cause clusterRelationship: Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Technical reviewBest possible solution: Land the narrow launch-path fix after normal check gating, retaining the identified AppKit Settings window as the sole preferences UI. Do we have a high-confidence way to reproduce the issue? Yes from current source and the supplied packaged-app trace: main has the empty scene and lacks the launch refusal, while the PR describes the reproducible launch sequence and after-fix window enumeration. Is this the best way to solve the issue? Yes: declining an untitled document window is the narrow fix for a menu bar app, and the fallback guard protects restored placeholders without replacing the retained AppKit Settings path. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against e6179f4045e0. LabelsLabel changes:
Label justifications:
EvidenceWhat I checked:
Likely related people:
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
|
2 participants
Resolves #3053
Summary
Fixes the blank CodexBar Settings window that opens on every launch, including launch at login (#3053).
CodexBarApp.bodydeclares exactly one scene:Settings { EmptyView() }. The real preferences UI movedto the AppKit
SettingsWindowControllerin #3029, and the hidden keepaliveWindowGroupwas removed in#3003 — which shipped in 0.52.0, exactly where the reports start. With the keepalive gone, the empty
Settings scene is the app's only scene, so at launch macOS takes the "open untitled window" path and
SwiftUI fills it with that empty scene: a blank 900×450 "CodexBar Settings" window that has no sidebar
and no controls, because there is nothing in it to render.
Changes
AppDelegate.applicationShouldOpenUntitledFilereturnsfalse. A menu bar app has no untitled documentto open at launch or on reopen, and this is what actually keeps the placeholder window from being created.
PlaceholderSettingsWindowGuard(started inapplicationWillFinishLaunching) closes any windowSwiftUI names
com_apple_SwiftUI_Settings*— by identifier or frame autosave name — if the system everbrings one back through state restoration or a system-sent settings action. It never closes the AppKit
Settings window: that one is excluded both by identifier (
com.steipete.codexbar.settings) and by a liveidentity check against
SettingsWindowController.window.The SwiftUI
Settingsscene itself stays, soCommandGroup(replacing: .appSettings)keeps owning ⌘, andthe localized application-menu item — it just never gets presented.
Validation
macOS 26.5, freshly packaged bundle, windows enumerated with
CGWindowListCopyWindowInfo:the placeholder, reproduced.
which confirms the untitled-file path was the trigger rather than window restoration.
Settings...item; clicking it opens thereal 800×572 AppKit window with content (
AXGroup+ 3AXButton+AXStaticText), ⌘, keeps it, and bothmenu bar status items are present.
swift test --filter "AppDelegateTests|PlaceholderSettingsWindowGuardTests"— 7 tests, passmake test— 2 failures inAdaptiveRefreshTimerTests(CancellationErrorin the two "long idle timer"tests). These reproduce identically with this branch's changes stashed, so they are pre-existing timing
flakiness on this machine, not from this change.
make check— 0 violations, no reformattingNotes
No screenshots: the user-visible change is the absence of a window at launch, which the window-list
evidence above captures more precisely than a screenshot would.