Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Closed
#4,101 1 comment 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
62/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
macos, swift

Research direction

Start in Sources/CodexBar/DockIconController.swift, especially shouldPromoteForPresentedWindow, and reproduce the launch path with CODEXBAR_STATUS_ITEM_DIAGNOSTICS=1 on macOS 27.0. Check whether the empty SwiftUI Settings placeholder is counted as presented during startup. Done means launching and relaunching CodexBar no longer leaves a Dock icon when no usable Settings window is shown.

Written by the indexing model from the issue text.

Description

clawsweeper:fix-shape-clear clawsweeper:queueable-fix clawsweeper:source-repro impact:ux-friction issue-rating: 🦞 diamond lobster no-stale P2

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.

Dominant language
Swift
Stars
21.9k
Forks
2k
Avg merge
21h 23m
Merged PRs (30d)
438

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from steipete/CodexBar

All issues in steipete/CodexBar

Similar issues

More Swift issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.