Enable settings window minimization

[Yuxin-Qiao]

Summary

• Enable the native minimize button on the SwiftUI Settings window.
• Add a regression test covering the window style mask and button state.

Root cause

The Settings scene's AppKit window did not include NSWindow.StyleMask.miniaturizable. The traffic-light control was therefore present but disabled, so macOS rendered the middle button as a gray circle without the – glyph.

Runtime proof (macOS)

Built a fresh arm64 debug bundle from this PR and opened the real SwiftUI Settings scene in an isolated HOME with Keychain access suppressed. The local-only launch hook used to open the scene was removed before pushing; it is not part of this change.

The live window reported:

styleMask = 32783
isMiniaturizable = true
standardWindowButton(.miniaturizeButton).isEnabled = true
AXSubrole = AXMinimizeButton
AXEnabled = true

Redacted title-bar capture from that run (the yellow traffic-light is the enabled minimize control):

Validation

• CODEXBAR_SUPPRESS_TEST_KEYCHAIN_ACCESS=1 swift test --filter SettingsWindowAppearanceTests — 13 passed
• make check — SwiftFormat and SwiftLint clean
• CODEXBAR_SUPPRESS_TEST_KEYCHAIN_ACCESS=1 make test — 861 selections in 72 groups passed; 0 failures, retries, or timeouts

CI classification (2026-08-16)

• Head 21d31e150deab023d3bae9b5639bb1d8609331a8 has green Linux, lint, and change-detection jobs.
• The aggregate lint-build-test failure is the repository's Draft-policy gate reporting that macOS Swift tests are deferred; it is not a test or implementation failure.
• The PR remains Draft and needs only maintainer review.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed August 16, 2026, 12:38 AM ET / 04:38 UTC.

ClawSweeper review

What this changes

The PR adds the native miniaturizable window style to CodexBar’s Settings window, covers it with an AppKit regression test, and includes a runtime screenshot of the enabled control.

Merge readiness

⚠️ Ready for maintainer review - 1 item remains

This is a focused, correct UI bug fix with sufficient real macOS proof and no blocking review findings; it should remain open for normal maintainer merge review.

Priority: P3
Reviewed head: 21d31e150deab023d3bae9b5639bb1d8609331a8

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	A small, well-scoped fix with direct runtime proof and focused regression coverage.
Proof confidence	🦞 diamond lobster (5/6) ✨ media proof bonus	Sufficient (screenshot): The PR supplies a redacted live macOS title-bar capture showing the enabled minimize control, corroborated by recorded runtime window and accessibility state.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Verified	Sufficient (screenshot): The PR supplies a redacted live macOS title-bar capture showing the enabled minimize control, corroborated by recorded runtime window and accessibility state.
Evidence reviewed	6 items	Current main lacks the requested style: The current Settings-window bridge adds resizability and full-size content but does not add the miniaturizable style; the branch adds only that missing native style flag. Existing reopen path handles minimization: The Settings presentation helper already deminiaturizes a minimized window before bringing it forward, so the added control remains compatible with reopening Settings. Regression coverage exercises the bridge: The added test attaches the bridge to a titled NSWindow and checks the style, miniaturizable state, and enabled standard minimize button.
Findings	None	None.
Security	None	None.

How this fits together

CodexBar’s SwiftUI Settings scene uses an AppKit bridge to configure its native window. That bridge controls the title bar and standard macOS window controls presented to the user.

flowchart LR
A[SwiftUI Settings scene] --> B[AppKit window bridge]
B --> C[Window style setup]
C --> D[Native title bar]
D --> E[Enabled minimize control]

Loading

Before merge

• Complete next step (P2) - No repair lane is needed because the submitted patch has no concrete review defect and includes sufficient real behavior proof.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Patch scope	3 files; production +3, tests +16, 1 runtime-proof image	The production behavior change is minimal and directly covered by a focused AppKit test plus visible runtime evidence.

Technical review

Best possible solution:

Merge this narrow bridge-and-regression-test change after routine maintainer review; the existing presentation path already restores a minimized Settings window when reopened.

Do we have a high-confidence way to reproduce the issue?

Yes, by source inspection: current main’s bridge configures a titled Settings window without adding the miniaturizable style, and the supplied focused test exercises that exact bridge path.

Is this the best way to solve the issue?

Yes. Adding the missing native style at the single Settings-window configuration point, with an assertion that the standard button is enabled, is the narrowest maintainable repair.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 1634eb2d99d9.

Labels

Label changes:

• add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
• remove rating: 🦞 diamond lobster: Current PR rating is rating: 🐚 platinum hermit, so this older rating label is no longer current.

Label justifications:

• P3: This is a contained macOS title-bar usability correction with limited blast radius.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (screenshot): The PR supplies a redacted live macOS title-bar capture showing the enabled minimize control, corroborated by recorded runtime window and accessibility state.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR supplies a redacted live macOS title-bar capture showing the enabled minimize control, corroborated by recorded runtime window and accessibility state.
• proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. The PR supplies a redacted live macOS title-bar capture showing the enabled minimize control, corroborated by recorded runtime window and accessibility state.

Evidence

What I checked:

• Current main lacks the requested style: The current Settings-window bridge adds resizability and full-size content but does not add the miniaturizable style; the branch adds only that missing native style flag. (Sources/CodexBar/PreferencesView.swift:371, 1634eb2d99d9)
• Existing reopen path handles minimization: The Settings presentation helper already deminiaturizes a minimized window before bringing it forward, so the added control remains compatible with reopening Settings. (Sources/CodexBar/PreferencesView.swift:234, 1634eb2d99d9)
• Regression coverage exercises the bridge: The added test attaches the bridge to a titled NSWindow and checks the style, miniaturizable state, and enabled standard minimize button. (Tests/CodexBarTests/SettingsWindowAppearanceTests.swift:201, 8f57ae251b63)
• Real behavior proof: The prepared 560×180 screenshot visibly shows the enabled yellow minimize traffic-light control; the PR body also records live window accessibility and enabled-state output from a fresh bundle. (docs/screenshots/settings-minimize-after.png, 21d31e150dea)
• Feature-history routing: Current configuration lines blame to the v0.50.0 baseline commit authored by Peter Steinberger; history also records KGBos’s recent Settings-window Stage Manager work. (Sources/CodexBar/PreferencesView.swift:367, 0e453c4a5b2a)
• Not already implemented on main: The current release tag points to the v0.50.0 baseline, while the PR’s source and test changes remain outside current main. (Sources/CodexBar/PreferencesView.swift:371, 21d31e150dea)

Likely related people:

• steipete: Peter Steinberger authored the current-main baseline blamed for the window-style bridge and is the dominant contributor in the sampled file history. (role: current Settings-window owner; confidence: high; commits: 0e453c4a5b2a, 1634eb2d99d9; files: Sources/CodexBar/PreferencesView.swift, Tests/CodexBarTests/SettingsWindowAppearanceTests.swift)
• KGBos: Recent history includes the focused Stage Manager Settings-window change, adjacent to the presentation behavior exercised by this fix. (role: recent Settings-window contributor; confidence: medium; commits: 6697bf399325; files: Sources/CodexBar/PreferencesView.swift)

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

History

Review history (3 earlier review cycles)

• reviewed 2026-08-15T03:35:34.803Z sha 8f57ae2 :: needs real behavior proof before merge. :: none
• reviewed 2026-08-15T04:24:51.515Z sha 21d31e1 :: needs maintainer review before merge. :: none
• reviewed 2026-08-15T18:54:30.993Z sha 21d31e1 :: needs maintainer review before merge. :: none

[Yuxin-Qiao]

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event exact_review_queue).
Result: when the review finishes, ClawSweeper will create the durable review comment if needed or update the existing comment in place.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

[steipete]

Thanks @Yuxin-Qiao! This landed via #2969, which keeps your style-mask change and test, and additionally fixes an interaction it exposed: minimizing Settings dropped the app back to accessory policy, which removed the window's Dock tile and stranded it. #2969 keeps regular policy while Settings is minimized and deminiaturizes on reopen. The changelog credits you.