Summary
On macOS 27.0, selecting Settings... from the CodexBar-Mobile menu highlights and dismisses the menu, but no Settings window appears. The app remains running and responsive.
This is reproducible in the packaged Mobile build based on upstream v0.52.0. The live macOS log identifies the selector-based Settings opener as the failing path. Upstream v0.53.0 / steipete/CodexBar#3029 appears to contain the required fix.
Environment
- macOS 27.0 beta
- CodexBar-Mobile 0.52.0.1
Steps to reproduce
- Launch CodexBar-Mobile.
- Open its menu-bar menu.
- Select Settings....
Actual behavior
The menu closes, but no Settings window is created or shown. CodexBar continues running; there is no crash.
When the item is selected, the unified log records two AppKit sendAction: attempts followed by:
[com.apple.runtime-issues:SwiftUI] Please use SettingsLink for opening the Settings scene.
Expected behavior
The Settings window should open in front on the active Space.
Root cause evidence
The installed commit's SettingsWindowOpener calls:
NSApp.sendAction(Selector(("showSettingsWindow:")), to: nil, from: nil)
NSApp.sendAction(Selector(("showPreferencesWindow:")), to: nil, from: nil)Source: https://github.com/o1xhack/CodexBar-Mobile/blob/mobile-dev/Sources/CodexBar/SettingsWindowOpener.swift
The macOS 27 runtime rejects this presentation route and requests SettingsLink. The selector dispatch can therefore appear handled without producing a visible Settings window.
Upstream resolution
Upstream v0.53.0 includes Fix Settings window opening:
That change replaces the selector-based opener with a retained Settings window controller and explicitly handles menu tracking, activation, window ownership, and presentation outcome.
The fork's general v0.53.0 sync is already tracked by #95. This focused issue can be used to verify that the Settings fix is preserved during that sync.
Suggested acceptance checks
- Sync or cherry-pick the upstream Settings window controller fix.
- On macOS 27, verify both the menu item and
Command-, open one retained Settings window in front.
- Verify repeated opens reuse and foreground the same window.
- Verify the window follows the active Space / Stage Manager stage.
- Confirm the SwiftUI runtime fault no longer appears.
Summary
On macOS 27.0, selecting Settings... from the CodexBar-Mobile menu highlights and dismisses the menu, but no Settings window appears. The app remains running and responsive.
This is reproducible in the packaged Mobile build based on upstream v0.52.0. The live macOS log identifies the selector-based Settings opener as the failing path. Upstream v0.53.0 / steipete/CodexBar#3029 appears to contain the required fix.
Environment
Steps to reproduce
Actual behavior
The menu closes, but no Settings window is created or shown. CodexBar continues running; there is no crash.
When the item is selected, the unified log records two AppKit
sendAction:attempts followed by:Expected behavior
The Settings window should open in front on the active Space.
Root cause evidence
The installed commit's
SettingsWindowOpenercalls:Source: https://github.com/o1xhack/CodexBar-Mobile/blob/mobile-dev/Sources/CodexBar/SettingsWindowOpener.swift
The macOS 27 runtime rejects this presentation route and requests
SettingsLink. The selector dispatch can therefore appear handled without producing a visible Settings window.Upstream resolution
Upstream v0.53.0 includes Fix Settings window opening:
That change replaces the selector-based opener with a retained Settings window controller and explicitly handles menu tracking, activation, window ownership, and presentation outcome.
The fork's general v0.53.0 sync is already tracked by #95. This focused issue can be used to verify that the Settings fix is preserved during that sync.
Suggested acceptance checks
Command-,open one retained Settings window in front.