We maintain an SFAuthorizationPluginView-based authorization plugin (mechanisms registered in system.login.console) on macOS 26 (Darwin 25.x) and are seeing a cosmetic but user-visible issue at the login window that we believe originates in the host, not our code. We'd like to confirm whether it's expected behavior or a bug worth filing via Feedback.
Setup
- Two local users, A and B. Our plugin adds a custom mechanism to the login chain, so after credential submission the host may present additional UI (our mechanism's view).
- Each authorization round runs in a fresh SecurityAgentHelper process (verified via PID in logs), so no state of ours survives between rounds.
Reproduction
- Log out of user A at the login window.
- Select user B and type their password.
- Submit. Our mechanism (invoked after submission, e.g. an enrollment prompt for a not-yet-enrolled user) presents its UI.
Observed
For roughly 1.1–1.4 s between our mechanism's window appearing and covering the host's, the login window shows user A's name/avatar tile — the previously selected user — before our panel covers it. Instrumentation confirms:
- Our process logs willActivate(withUser:) delivering user A (the previous round's user) while the authorization context (GetContextValue on kAuthorizationEnvironmentUsername) correctly contains user B.
- The stale tile renders inside what appears to be the host's own window (class LUI2Window, created ~300 ms before our surface activates). Our code makes no writes to the engine context at that point (we log every SetContextValue; zero writes occurred during the flip window).
- The flip only happens when our mechanism round starts after credential submission. If the mechanism round starts before user selection (the normal login path), each user click produces a fresh willActivate with the correct name and no flip is visible.
Question
Why does the login window display the previous round's user (user A) after I've selected and submitted credentials for user B? The willActivate(withUser:) callback our mechanism receives still carries user A at that moment, while the authorization context already contains user B — the two disagree. Is the host intentionally re-showing the last logged-in user's tile when a mechanism presents UI after credential submission, and can a mechanism do anything to prevent it?
We'd like to confirm whether it's expected behavior or a bug worth filing via Feedback.
If it’s annoying, it’s worth filing a bug about it. I like to think about it this way:
- Either it’s a bug.
- Or it’s working as designed, in which case you’re actually filing a bug against the design.
If you do file a bug about this, it’d help if you included a minimal test project that illustrated the issue. One good option here is to try reproducing it with QAuthPlugins. If it reproduces directly, you can include that. If not, apply your tweaks until it does.
Oh, and also make sure to include a sysdiagnose log taken shortly after reproducing the issue.
Oh, and if you can get a screen recording, that’d be grand. Historically you could do this by SSHing into the affected machine and recording the screen using the screencapture tool. I think that still works but, if not, you can always record the screen using your iPhone.
When you’re done, please post your bug number, just for the record.
Finally, be mindful of this response )-:
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"