macOS 26: Lumen runs but no menu-bar/topbar icon appears, leaving no UI entry point

[alexkubica]

Summary

After installing lumen-app on macOS, Lumen starts and its daemon is running, but no menu-bar/topbar icon appears. Because both Tauri windows are hidden at startup, this leaves no visible UI entry point: I cannot open the tray popover, main window, or the in-app fault reporter.

A local screenshot (Downloads/lumen-process.png) shows macOS listing Lumen as running with 2 processes and about 150 MB memory, but no Lumen UI/topbar item is visible.

Environment

• macOS: 26.5.2 (25F84)
• Architecture: arm64
• Install method: Homebrew cask
• Installed package: lumen-app 1.5.0
• App path: /Applications/Lumen.app
• Release: v1.5.0, asset Lumen_1.5.0_aarch64.dmg, published 2026-07-30T18:41:01Z
• Bundle identifier: io.speedata.lumen

What I did

1. Installed with Homebrew cask (lumen-app).
2. The app was launched by the cask postflight / login item.
3. Checked the macOS topbar/menu bar for the Lumen icon.
4. Searched for the process and app windows.

Expected

A Lumen menu-bar/topbar icon appears. Left-click should open the compact panel and right-click should expose Open Lumen / Quit Lumen, as documented.

Actual

• No Lumen icon appears in the macOS topbar/menu bar.
• No main window or panel is visible.
• macOS process search shows Lumen running.
• System Events reports the Lumen process is visible but has zero windows.
• The bundled daemon is running.
• lumen is not on PATH, so the terminal fault-report path in the docs is not available unless the CLI is installed separately or through the hidden UI.

Observed commands:

$ brew list --versions | rg -i '^lumen|hackpoint|lumen'
lumen-app 1.5.0

$ command -v lumen; lumen --version
zsh:1: command not found: lumen

$ /Applications/Lumen.app/Contents/MacOS/lumen-cli --version
lumen 1.5.0

$ ps aux | rg -i '[l]umen'
... /Applications/Lumen.app/Contents/MacOS/Lumen
... /Applications/Lumen.app/Contents/MacOS/lumen-daemon

$ osascript -e 'tell application "System Events" to tell process "Lumen" to return {frontmost, visible, count of windows, name of windows}'
false, true, 0,

Source-code notes / possible causes

I looked through main to understand the startup path.

• lumenator/src-tauri/tauri.conf.json defines both main and panel with "visible": false. If tray creation succeeds but the tray item is invisible/not rendered, or if tray creation fails in release without surfacing diagnostics, there is no fallback window.
• lumenator/src-tauri/src/lib.rs sets tauri::ActivationPolicy::Accessory, then builds the tray via TrayIconBuilder::with_id("lumen-tray"), using a custom transparent 44x44 RGBA icon and .icon_as_template(false).
• The installed bundle has LSRequiresCarbon = 1, no LSUIElement, and no LSBackgroundOnly:

$ plutil -p /Applications/Lumen.app/Contents/Info.plist
...
"LSRequiresCarbon" => true
...

• The app is ad-hoc signed and spctl reports the same signature/resource issue documented in the repo's pre-release notes:

$ codesign -dv --verbose=4 /Applications/Lumen.app
Signature=adhoc
Info.plist=not bound
Sealed Resources=none

$ spctl -a -vv /Applications/Lumen.app
/Applications/Lumen.app: code has no resources but signature indicates they must be present

• macOS unified logs do not show an obvious Lumen panic, and WebKit appears to load resources, but there are repeated startup-time errors around AppIntents/linkd and WebContent sandboxed access to pasteboard/launchservices. I am not sure whether these are causal or normal WebKit noise on macOS 26.

Relevant log excerpts:

Error registering app with intents framework: Error Domain=NSCocoaErrorDomain Code=4097
CONNECT: Attempt to connect to launchservicesd prohibited because kLSServerConnectionStatusProcessIsDaemonMask is set.
WebProcess::markAllLayersVolatile: Failed to mark layers as volatile for webPageID=8

Secondary packaging observation

The login item created on this install is labeled Lumen, not io.speedata.lumen:

$ plutil -p ~/Library/LaunchAgents/Lumen.plist
{
  "Label" => "Lumen"
  "ProgramArguments" => [
    0 => "/Applications/Lumen.app/Contents/MacOS/Lumen"
  ]
  "RunAtLoad" => true
}

But the cask currently has:

uninstall quit:       "io.speedata.lumen",
          launchctl:  "io.speedata.lumen"

zap trash: [
  "~/Library/LaunchAgents/io.speedata.lumen.plist",
]

That may be separate from the missing topbar icon, but it looks like uninstall/zap may miss the actual LaunchAgent from this install.

Why this is hard to self-report from Lumen

The documented fault reporter lives behind the app UI. In this failure mode there is no visible tray icon/window, and lumen is not on PATH, so I cannot reach either the in-app reporter or the documented terminal lumen report --dry-run flow without manually invoking the bundled sidecar binary.

[HackPoint]

Thanks for the report — this is a real gap and 1.5.1 addresses half of it.

What 1.5.1 changes. When the tray cannot be built, Lumen now shows the main window
instead of staying invisible. Both windows start hidden by design, so a tray failure
previously left the app running with no popover, no window, and no way to reach the fault
reporter — including no way to report this. That is fixed. It is not a fix for whatever
makes the tray fail on your machine, which I still cannot reproduce on the same OS version;
it is the difference between a degraded app and an unusable one.

The cask also had a second bug your report exposed: uninstall unloaded
io.speedata.lumen, but launchctl matches on the agent's Label and the plugin writes
Lumen.plist with Label Lumen. Every uninstall left a login item behind, still trying to
launch a deleted app at each boot. If you have uninstalled at any point, you may have a
stale one:

launchctl list | grep -i lumen
launchctl bootout gui/$UID/Lumen 2>/dev/null
rm -f ~/Library/LaunchAgents/Lumen.plist

What I still need from you to fix the actual cause. The tray build result is logged.
Could you post the line?

grep 'TRAY:' ~/Library/Logs/io.speedata.lumen/Lumen.log | tail -20

A TRAY: build failed: line carries the underlying error, and that error is the thing I am
missing — every hypothesis I have (icon asset, activation policy, a status-item slot denied
under a full menu bar) predicts a different message. Also useful:

• sw_vers output, and whether the menu bar is unusually crowded / you use a menu-bar
  manager (Bartender, Ice, etc.)
• whether the two processes are Lumen + a helper, from pgrep -fl -i lumen

Please upgrade to 1.5.1 first (brew upgrade --cask lumen-app) — with the fallback in
place you should at least get a window, which also tells me the tray is the only thing
failing rather than something earlier in startup.

[HackPoint]

Correction: I asked you for a file that cannot exist. Sorry.

I asked for TRAY: build failed: from ~/Library/Logs/io.speedata.lumen/Lumen.log. That log
file is never created in a released build — the logger is registered under
if cfg!(debug_assertions), so in the shipped binary every log call goes to a no-op sink.
There was nothing for you to find. That was my error, not a missing file on your machine, and
the same wrong instruction went into the 1.5.1 CHANGELOG. Both are now corrected.

And I think I know what this is.

Hold ⌘ and you can drag menu-bar icons around — including dragging one off the bar. macOS
persists that removal into the app's own preferences, and it is permanent: every later launch
creates the status item and then immediately hides it. Crucially, nothing fails — the tray
builds successfully, the app logs success, and the fallback I shipped in 1.5.1 never triggers,
because from the code's point of view everything worked. That matches your report exactly,
including the part I could not explain before: why it doesn't reproduce for me. It's per-user
preference state, not an OS version.

On my machine Lumen already has the sibling key (NSStatusItem Preferred Position Item-0), so
the autosave mechanism is definitely active for this app.

The one command that would confirm it:

defaults read io.speedata.lumen | grep NSStatusItem
defaults read Lumen | grep NSStatusItem

Please check both — Lumen has written under both domain names. Looking for:

"NSStatusItem Visible Item-0" = 0;

If that's there, it's the cause, and this fixes it immediately:

defaults delete io.speedata.lumen "NSStatusItem Visible Item-0"
defaults delete Lumen "NSStatusItem Visible Item-0"
killall Lumen; open -a Lumen

(A Preferred Position key alone is normal — that's just where the icon last sat.)

Also worth asking directly: have you ever ⌘-dragged icons around your menu bar, or dragged
one off it?

If that key isn't there, the next most likely causes are a menu-bar manager (Bartender, Ice,
Hidden Bar…) holding it in an overflow section, or simply a full menu bar — macOS doesn't queue
status items, so if there's no room the item exists and is never drawn. The full diagnosis path,
including a step that isolates whether the login-item launch environment is involved, is here:
docs/troubleshooting-the-tray.md

Meanwhile, one thing that works today — the CLI inside the bundle doesn't need the window:

/Applications/Lumen.app/Contents/MacOS/lumen-cli report --dry-run

What I'm changing regardless of your answer:

• Logging actually enabled in release builds, so the next report has real evidence
• Lumen clears that persisted-hidden state on startup, and tells you it did rather than
  silently overriding a choice you may have made deliberately
• Detection for "the tray built fine but no icon is visible" — the case that currently slips
  through every check
• open -a Lumen / double-clicking in /Applications will reveal the window (today it does
  nothing at all, which is its own bug)
• A lumen doctor command so this is one paste instead of nine rounds of questions

Thanks for reporting this — it turned up four separate defects, and the one above is the kind
that would have sat there indefinitely.

[HackPoint]

Where this stands

The ⌘-drag mechanism is now handled and verified in the shipping bundle — the cause on your machine
is still unconfirmed. Verified: Lumen detects a persisted NSStatusItem Visible preference set to
false, clears it before building the tray, then confirms the icon is actually on screen. I tested
that by planting the preference and launching the installed app, in the app's own preference domain.

Not verified: that an uncleared preference is what hides your icon. Nobody has reproduced the
symptom itself, so it fits every observation and remains a hypothesis.

Two corrections to what I posted earlier

First, I said a menu-bar manager (Ice) was present on my machine and called it a leading
alternative. That was wrong — Ice has never been installed here. My own new lumen doctor command
reported it because it matched manager names as substrings of the whole process list, and "ice" is a
substring of "Services": 130 processes matched on a stock macOS install. It would have invented a
phantom cause on almost any Mac. Fixed, and my apologies for the noise.

The manager question is still worth asking on its own merits, just not because of anything I found:
do you run Bartender, Ice, Hidden Bar, Dozer, Vanilla, TopNotch or Barbee? If so, is the icon in its
hidden section?

Second, while testing I found a second preference key form that the fix was missing entirely:

NSStatusItem Visible Item-0      <- the form I was looking for
NSStatusItem VisibleCC Item-0    <- also real, and it was being ignored

CC is Control Center. It is not a typo and not Lumen's — Apple's own TextInputMenuAgent and
Control Center both use it, as does OneDrive. On my machine Lumen's was set to false while every
other app's was true. So there was a hidden-icon flag that the fix could not see. Now handled.

This makes your output more useful than before

When you have a moment, both forms would show up in:

defaults read io.speedata.lumen | grep NSStatusItem
defaults read Lumen | grep NSStatusItem

Either key set to 0 would explain the symptom. No such key is just as useful — it rules the
hypothesis out and points me elsewhere. Decline freely; the fixes ship either way.

Shipping in 1.6.0 (no date from me)

• logging actually enabled in release builds — the earlier build wrote no log at all, which is why
  the line I first asked you for could not exist
• both visibility key forms cleared at startup, and announced rather than silently overridden
• "the tray built" no longer treated as "the icon is visible": the item's on-screen rectangle is
  checked after startup, and a full menu bar is reported as such instead of being papered over
• nothing in startup can abort it any more; a degraded launch says so in the UI
• open -a Lumen and double-clicking the app now reveal the window — verified, it previously did
  nothing at all
• lumen show, and lumen doctor for the whole diagnosis in one paste

Full path if you want it: docs/troubleshooting-the-tray.md