[ibalat]

Fixes #230.

Problem

oidc::wait_for_authorization_code always passed open_browser = true, so every enrollment attempt called open::that_detached on the daemon's landing page, regardless of how the daemon runs. docs/device-identity.md says a system service "cannot open a browser; its attempt to do so fails and is only logged", but on macOS it does not fail: open run by the root LaunchDaemon reaches the console session, and because root has no default-browser preference, LaunchServices starts Safari on http://127.0.0.1:51327/ ("Continue to sign in"). The user then has an unexpected Safari window on the landing page next to their own browser, which the desktop app's Enroll device opens straight on the IdP. On Linux services it is the stuck xdg-open attempt that the detached spawn comment already works around.

Change

• oidc::opens_browser(user_mode, attached_to_terminal): the daemon opens the browser only when it runs in the user's session, i.e. --user mode or started from a terminal (sudo agentdesktop daemon ... during development). daemon.rs evaluates it once from the resolved user flag and stdin.is_terminal() and passes it through remote::run → run_session → oidc::enroll → wait_for_authorization_code.
• A LaunchDaemon, Windows service, or systemd unit (no user mode, no terminal) no longer tries: the URL is still printed, logged, and published on /v1/enrollment for the desktop app and agentdesktop enrollment.
• The device-authorization flow and the LLM gateway sign-in are unchanged.
• docs/device-identity.md: step 4 of the browser flow now describes the behaviour (and why the old attempt was not harmless on macOS).

Testing

• cargo clippy -p agentdesktop-agent --all-targets -- -D warnings, cargo fmt --all --check
• cargo test -p agentdesktop-agent --lib -- oidc::tests remote::tests (48 passed, including the new only_a_daemon_in_the_user_session_opens_a_browser)
• Observed on macOS 26 / v0.5.0 PKG (Jamf, LaunchDaemon, Entra): Safari opened on the landing page after every install/daemon restart while the user's default browser is a different one. I could not rebuild a signed PKG to re-verify on the managed device; the behaviour follows from open_browser no longer being set for the LaunchDaemon (no --user, stdin is /dev/null).

[Copilot]

🟢 Approval recommended

No active review issues were identified for the enrollment browser-policy change.

No open issues 🎉

What changed in this PR

Addresses #230 by preventing background system daemons from launching an enrollment browser, avoiding unexpected Safari windows on macOS. Desktop and CLI clients retain access to the sign-in URL.

Changes:

• Allows automatic browser opening only in user mode or when attached to a terminal.
• Passes that policy through device enrollment without changing device-authorization or LLM gateway sign-in.
• Adds browser-policy unit coverage and updates the enrollment documentation.

File	Description
docs/​device-identity.md	Documents system-service behavior and the macOS browser issue.
crates/​agent/​src/​remote.rs	Passes the browser policy through enrollment sessions and retries.
crates/​agent/​src/​oidc.rs	Defines and tests the policy and applies it to browser-based enrollment.
crates/​agent/​src/​daemon.rs	Determines browser permission from the resolved user mode and terminal attachment.

_{Review effort: Balanced}

[yuval-k]

over lgtm; but what does the std::io::stdin().is_terminal() check adds here?

[ibalat]

@yuval-k thanks for the review, and good catch! 🙏

That check was meant to keep the auto-open for sudo agentdesktop daemon during development. But that daemon runs as root too, so it hits the same problem this PR fixes (Safari on macOS, and browsers refuse to run as root on Linux).

I've dropped it: the daemon now opens the browser only in --user mode. A system-mode daemon started from a terminal still prints the sign-in URL, so nothing is lost. Thanks again!