[client] launch macOS GUI as the logged-in user after install/update - #6962
[client] launch macOS GUI as the logged-in user after install/update#6962riccardomanfrin wants to merge 6 commits into
Conversation
Wails already does this: the GUI is started by a per-user LaunchAgent. So starting the GUI assumes there is a user that is logging in to refer to. We are aligning the auto-update to this model here. IF there is a user, restart the GUI otherwise wait for a login. WHY it didn't happen before 0.75: cause the Fyne GUI never wrote any ui_preferences.json file or any other in users $HOME folder. So it's a problem related to the new GUI and has nothing to do with MDM.
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThe changes log missing UI preferences and make macOS GUI startup validate the active console user before launching under that user’s context. ChangesPreferences and macOS GUI launch
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@release_files/darwin_pkg/postinstall`:
- Around line 43-45: Update the console-user launch flow around uid and
launchctl asuser to validate that the id -u lookup succeeds and returns a
non-empty UID before attempting launch. When lookup fails, handle it explicitly
instead of invoking launchctl with an empty UID; preserve the existing launch
behavior for valid users and avoid masking this failure with || true.
- Line 45: Update the GUI launch command in the postinstall flow to resolve and
validate the target user’s UID before calling launchctl, failing visibly when
lookup fails instead of swallowing errors with || true. Set HOME to the resolved
user’s HomeDir, consistent with the installer’s existing user-path handling,
when invoking launchctl asuser to open APP.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 525b87c4-c0c1-425a-8f70-7e400630476d
📒 Files selected for processing (2)
client/ui/preferences/store.gorelease_files/darwin_pkg/postinstall
Release artifactsBuilt for PR head
GHCR images (amd64)
This comment is updated by the Release workflow. Artifact links expire according to the workflow retention policy. |
Address CodeRabbit review on the pkg postinstall: resolve and validate the console user's uid and home dir before launching, skip visibly instead of masking with `|| true`, and set HOME to the resolved home so the GUI reads the user's real ui-preferences.json.
…LOGNAME) Both launch paths (pkg postinstall and the updater's startUIAsUser) run as root, so launchctl asuser alone moves the launch into the user's GUI domain but leaves root's HOME/USER/LOGNAME. Use sudo -u <user> -H to drop to the console user with their environment, fixing os.UserConfigDir() resolution. Drops the space-fragile dscl/awk home lookup and the duplicate-HOME append; extracts consoleUser() and aligns the skip list across both paths.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@client/internal/updater/installer/installer_run_darwin.go`:
- Line 113: Update the launch command execution in Start() to wait for launchctl
to finish and propagate its exit error, replacing Process.Release() with Run()
or an equivalent Start()/Wait() flow. Preserve the existing command arguments
and return the failure from launchctl, sudo, or open to the caller.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: da71b953-aa0d-4302-913a-3102ad67ad8f
📒 Files selected for processing (2)
client/internal/updater/installer/installer_run_darwin.gorelease_files/darwin_pkg/postinstall
🚧 Files skipped from review as they are similar to previous changes (1)
- release_files/darwin_pkg/postinstall
Replace Start()+Process.Release() with Run() in startUIAsUser: the launchctl/sudo/open chain is short-lived (open returns once LaunchServices accepts the request), so waiting surfaces a launch failure to the caller instead of swallowing it. Addresses CodeRabbit review.
|



Describe your changes
In unattended installs/updates there may be no logged-in user, so there's no context to start the GUI (nor anyone to see it).
The bug is the GUI being started in the wrong user context / inheriting the wrong
$HOME(OS mechanics aside).Today the GUI is started by a per-user LaunchAgent, i.e. on behalf of the user who logs in — no login ⇒ no GUI.
The patch aligns to this: it launches the GUI on behalf of the logged-in console user if one exists, otherwise it delegates the launch to the per-user LaunchAgent at next login.
Additionally it logs when default UI settings are applied.
Note (small caveat): the LaunchAgent auto-starts the GUI at login only once it's been registered — which happens on the first GUI launch in the user's context. On an MDM/unattended fresh install done with no user logged in (where the user has never run the GUI before), they may need to start it manually once; it self-registers from then on.
Issue ticket number and link
No public issue — reported internally (community report on Slack: macOS advanced-view + onboarding reset on every update, esp. via MDM/Munki). Buggy line on main:
netbird/release_files/darwin_pkg/postinstall
Line 33 in dd2bdc0
Stack
Checklist
Documentation
Select exactly one:
Internal macOS installer / GUI-launch behavior. No public API, CLI, or configuration change: the fix only changes the user context the desktop GUI is launched in after a pkg install/update.
Docs PR URL (required if "docs added" is checked)
Paste the PR link from https://github.com/netbirdio/docs here:
N/A
Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.Summary by CodeRabbit
Bug Fixes
Improvements