Dock icon stays after launch on macOS 27.0: accessory demotion silently fails

[tobihagemann]

CodexBar shows up in the Dock on every launch since I'm on macOS 27.0 (26A428), and it stays there. CodexBar 0.68.0 (159), installed in /Applications, LSUIElement is true and LaunchServices has it registered as ui-element.

It happens on a clean quit and relaunch, not only after a Sparkle update. Polling NSWorkspace.runningApplications from a separate process right after open -a CodexBar:

0.53s policy=1   (accessory)
0.67s policy=0   (regular, Dock icon appears)
... stays 0 for the rest of the 40s poll

With CODEXBAR_STATUS_ITEM_DIAGNOSTICS=1, the startup trace reports activationPolicy: 1 on every line from will-finish-launching to startup-check, while lsappinfo reports the process as type="Foreground". The SwiftUI Settings placeholder ({{840, 580}, {900, 450}}) is visible: true from did-finish-launching through rendered, and false at startup-check.

So my reading is: the visible placeholder qualifies for promotion in shouldPromoteForPresentedWindow, the app goes .regular, and the later setActivationPolicy(.accessory) doesn't take effect.

That last part looks like an OS bug rather than CodexBar's logic. A minimal AppKit app with LSUIElement = true reproduces it on 27.0:

func applicationDidFinishLaunching(_ n: Notification) {
    NSApp.setActivationPolicy(.regular)       // returns true, Dock icon appears
    print(NSApp.activationPolicy().rawValue)  // still prints 1 (accessory)
    DispatchQueue.main.asyncAfter(deadline: .now() + 1) {
        print(NSApp.setActivationPolicy(.accessory))  // false, Dock icon stays
    }
}

The in-process getter never leaves .accessory, and the switch back to .accessory returns false. I also tried re-setting .regular first, calling NSApp.activate first, and going through .prohibited (with and without a delay). .prohibited takes effect, but .accessory never does. Peekaboo shows the same symptom for the same reason. I haven't compared against an older macOS, so I can't say for sure it's new in 27.0, but it only started for me after updating.

Since the demotion can't be relied on, avoiding the promotion in the first place would sidestep it. For example, not counting the empty SwiftUI Settings placeholder as a presented Settings window at launch. Happy to test a build if that helps.

[clawsweeper]

Codex review: this still needs some work. Reviewed October 5, 2026, 2:54 AM ET / 06:54 UTC.

Summary
The launch defect remains actionable on current main and v0.72.0. The reporter explicitly withdrew the earlier fixed observation and reproduced the symptom again; no matching open fix PR was found.

Reproducibility: yes. for the owned eligibility defect: a visible SwiftUI Settings placeholder deterministically satisfies the current promotion predicate, and an existing test expects it. The macOS demotion failure is supported by the reporter’s trace but was not independently executed here.

Next step
The launch eligibility defect has a clear production owner and focused test seam, with no matching open fix PR found.

Review details

Best possible solution:

Exclude empty SwiftUI Settings placeholders from promotion and regular-policy retention while preserving real Settings, minimized Settings, and update-dialog behavior.

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

Yes for the owned eligibility defect: a visible SwiftUI Settings placeholder deterministically satisfies the current promotion predicate, and an existing test expects it. The macOS demotion failure is supported by the reporter’s trace but was not independently executed here.

Is this the best way to solve the issue?

Yes for the launch case: reusing the existing placeholder identity rules is a narrow repair that avoids unnecessary promotion. Removing promotion for real dialogs would undermine their established focus and restoration behavior.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Excluding the startup placeholder will not establish a fix for the separately reported macOS demotion failure after intentionally opening real Settings or update dialogs.

Codex review notes: model internal, reasoning medium; reviewed against 93abfbe22899.

Label changes

Label changes:

No label changes.

Label justifications:

• P2: The persistent launch Dock icon is a current, bounded UI defect without evidence that normal app use is blocked.
• impact:ux-friction: An unwanted Dock icon contradicts the documented menu bar launch behavior and creates avoidable user confusion.

Evidence reviewed

Acceptance criteria:

• swift test --filter DockIconPolicyDecisionTests
• swift test --filter PlaceholderSettingsWindowGuardTests
• make test
• make check

What I checked:

• Current promotion trigger: The Settings classification accepts the SwiftUI Settings identifier. The visible-window predicate therefore includes the empty placeholder, and reevaluation calls ensureRegularPolicy for it. Demotion depends on setActivationPolicy(.accessory) succeeding. (Sources/CodexBar/DockIconController.swift:78, 93abfbe22899)
• Placeholder is explicitly unwanted: The placeholder decision recognizes SwiftUI Settings naming through either identifier or frame autosave name, while protecting the registered AppKit Settings window. The source documents that the empty scene can appear during launch. (Sources/CodexBar/PlaceholderSettingsWindowGuard.swift:12, 93abfbe22899)
• Existing test encodes placeholder promotion: The first policy test constructs a SwiftUI Settings identifier and expects both regular-policy retention and promotion. This provides a focused regression seam that needs to distinguish the placeholder from real Settings. (Tests/CodexBarTests/DockIconPolicyDecisionTests.swift:7, 93abfbe22899)
• Expected launch behavior: The README describes a menu bar app with no Dock icon. Real Settings and update dialogs intentionally receive temporary Dock presence. (README.md:15, 93abfbe22899)
• Latest release still has the same policy: Current main and v0.72.0 resolve to identical Dock controller blobs (65ff4b07534be09bd67ce545003721eb84b97175) and placeholder guard blobs (d7f186a0f3fae12383c4fb9dbd42acb6385b520a). There is no intervening repair in these production owners. (Sources/CodexBar/DockIconController.swift, cfee869f3181)
• Reopened current-release reproduction: The October 5 reporter comment withdraws the September 29 fixed claim and reports recurrence on macOS 27.0.1 with CodexBar 0.71.0 and 0.72.0. It includes foreground-transition logs and reports that the minimal AppKit demotion example still fails: Dock icon stays after launch on macOS 27.0: accessory demotion silently fails #4101 (comment).

Likely related people:

• steipete: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• harjothkhara: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

How this review workflow works

• 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.

[tobihagemann]

Seems to be fixed in macOS 27.0.1, I can't reproduce it anymore.

[tobihagemann]

I closed this too early. I don't think it was ever fixed, I just experienced it again, this time on macOS 27.0.1 (26A434) and CodexBar 0.71.0, and then the same with 0.72.0 after updating. My guess is that it only disappeared after the restart.

The minimal AppKit repro from above still fails: setActivationPolicy(.regular) returns true, lsappinfo reports Foreground, and setActivationPolicy(.accessory) returns false. TransformProcessType to UIElement returns -50, and lsappinfo setinfo ApplicationType=UIElement from outside has no effect either.

On the CodexBar side, the system log shows the process going foreground about 90 ms after check-in on each of today's three launches:

08:37:31.896 launchservicesd CHECKIN:0x0-0x381c819 32348 com.steipete.codexbar
08:37:31.986 loginwindow     "CodexBar" (32348) transitioned to foreground-type

So not promoting for the empty SwiftUI Settings placeholder would still fix the launch case. Opening Settings or checking for updates would keep leaving the icon in the Dock until quit, since the demotion afterwards can't succeed. I haven't verified whether a fresh boot behaves differently.

[clawsweeper]

🦞🔧
ClawSweeper is automatically building a fix for this issue.

The issue review finished and no active implementation pull request was found.

Automatic implementation progress:

• State: Queued
• Detail: Review complete; no active implementation PR was found. The Codex implementation worker is queued.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/37280018644
• Updated: 2026-10-05T07:52:43.768Z
• Opt out: add clawsweeper:manual-only or clawsweeper:human-review.

[steipete]

Thanks @tobihagemann! Fixed in #4335 (merged as c3c6ce0): on macOS 27 the empty Settings placeholder window counted as a promotable window, so the accessory demotion silently failed and the Dock icon stayed; the placeholder is now excluded from Dock promotion and retention, with a deterministic regression. Ships in the next release.