Hi Quinn, Thanks again for clarifying the GUI-session LaunchAgent and XPC approach. We've completed a read-only review of the public APIs and have one remaining platform-identity question before implementing that design. Our target is macOS 26.6.2 (25G83), arm64, using C-XPC and a system-level daemon. We understand that xpc_connection_set_peer_code_signing_requirement can enforce an independently configured code requirement, and that SecCodeCreateWithXPCMessage can obtain a dynamic code reference from the actual received message. We also understand that xpc_connection_get_euid, get_asid and get_pid describe connection-time credentials. We need to establish two additional properties: Actual-message process identity Is there a supported public mechanism to establish that the received XPC message's authenticated sender corresponds to a particular kernel-observed process incarnation, including its account, audit session and PID version? Specifically, can we reliably associate that identity with the audit-token process identity obtained from a separate Mach message? We don't want to assume that matching PIDs, code identity or connection-time credentials proves process-incarnation equality, especially across forwarding, exec, replacement or reconnection. Particular GUI LaunchAgent instance How should our daemon establish that this authenticated process is the actual launchd-managed agent belonging to a particular GUI login session, rather than another same-UID process executing the same signed code? Does launchd expose a supported service-instance or bootstrap-domain binding that establishes this relationship? Or is a different communication arrangement recommended? We are not asking for instantaneous logout detection or atomic ordering against pending IPC. We understand those guarantees aren't provided. Our controller will enforce its own authorization epochs and retire authority upon observed agent loss or revocation. We are only trying to determine which process and GUI-session identity facts macOS can authoritatively supply, so our application can enforce the remaining rules. If either association is not available through supported public interfaces, confirmation of that limitation—or a recommended alternative architecture—would be equally useful. Thanks again for your help.

Hi Quinn, Thanks. The GUI-session LaunchAgent approach gives us a concrete direction. We have one remaining question about how our system-level controller should observe the agent's lifetime. What supported mechanism would you recommend for detecting termination or loss of the GUI-session LaunchAgent? Would an XPC connection with invalidation handling, process-exit observation, or another launchd-supported mechanism be appropriate? Does macOS provide any ordering guarantees between that observation and separate Mach IPC requests or replies already pending in our controller? Or should we assume the controller may process a request before learning that the GUI session ended? If that ordering is not guaranteed, is it reasonable for our application to maintain its own session-specific authorization epochs, invalidate them upon observed agent loss, and fail closed whenever session authority is uncertain? We are not requesting instantaneous notification or atomic synchronization with logout. We're trying to understand the supported macOS observation mechanism and its limits, so we can enforce the remaining authorization rules ourselves. Our target is macOS 26.6.2 (25G83), arm64. Thanks again for your guidance.

Thanks, Quinn. Our intended scope is the active local graphical login session. We are not seeking to authorize SSH or other remote login sessions. We need to determine whether the specific GUI login session associated with a request is still valid, and invalidate that authority when the session ends or changes. An account identity or console-user snapshot alone isn’t sufficient for that requirement. For that scope, what supported mechanism would you recommend?

Thanks, Quinn. Let me make this concrete. Our request/reply path uses Mach messages and a mediator. We validate the kernel-supplied audit token, code identity, account and request/reply correlation. The remaining question is the lifetime of the login session associated with the request. For example: A user is logged in, and a request originates from that login session. The mediator authenticates the sender. Before the request is authorized, the user logs out. Our intended policy is to reject that pending request. A subsequent login by the same UID must not make the old request eligible again. The same applies to a reply still pending when logout occurs. This describes the behavior we want to enforce, not a logout failure we have reproduced. Sender identity or continued process existence alone does not establish that the original login session remains valid. Is there a supported public mechanism to bind a request to that particular login session and check, at authorization time, that the session has not ended? Can SessionGetInfo using the audit token’s ASID establish this, or should we use another mechanism? If the available mechanism provides only a snapshot or asynchronous notification, understanding that limitation would help too. I also bundled separate issues into the earlier question. Fast user switching need not end the original login session; requiring the session to remain the active console session would be our policy. Revocation of permissions issued by our application is also ours to enforce. The question above is specifically about the macOS login-session boundary.

Hi Quinn, Thank you. Our 20-attempt non-reproduction result is already recorded above; we have no stuck-process backtrace or sysdiagnose to provide. We understand that SessionGetInfo is racy and that process identity and code-signing checks should use the kernel-provided audit token. One security question remains: on macOS 26.6.2 (25G83), arm64, is there a supported public mechanism or pattern for invalidating an authenticated request’s authority across logout, session switching or revocation before authorization, without assuming that a surviving process means its login-session authority remains valid? If no such guarantee is available, could you confirm that limitation? This concerns authorization semantics rather than further stall diagnostics. Thank you, Brian

Thanks, Quinn. We attempted to reproduce the earlier SessionGetInfo non-return so we could capture the sample backtrace you requested. We ran a bounded 20-attempt campaign on macOS 26.6.2 (25G83), arm64, using the same verified transferred binaries and the recorded invocation: ./WatchdogMach --observation-ms 15000 In all 20 attempts, SessionGetInfo returned with osstatus=0. Measured call durations ranged from 0.648 ms to 5.126 ms. We pre-armed monitoring to run /usr/bin/sample if the receiver remained blocked in the SessionGetInfo call for at least five seconds. That condition did not occur in any attempt, so we were unable to capture the requested stuck-process backtrace. We are treating this only as non-reproduction in this bounded campaign; we are not using it to infer API semantics or to invalidate the earlier >15-second observation. Would you recommend any additional instrumentation or a different way to capture useful diagnostics if the condition recurs?

Hi Quinn, Thank you again for your explanation of SessionGetInfo and its inherent race conditions. That clarified an important part of our design. We have two narrow follow-up questions concerning macOS 26.6.2 (25G83), arm64. Our Mach receiver obtains an audit session ID from a request while the separate sender remains alive, blocked waiting for a reply, and the receiver retains the corresponding send-once right. In our focused reproducer, SessionGetInfo(audit_asid, ...) does not return within a 15-second observation window. 1. Is SessionGetInfo guaranteed to return with either success or an error in finite time under these conditions, including when its backing service is unavailable? 2. Is there any supported public API or pattern for authoritatively validating current audit-session liveness at authorization time? Or should we treat such a guarantee as unavailable? We're designing the system to fail closed and do not want to rely on undocumented timing or session-liveness assumptions. Thank you for your guidance.

Thanks - this is exactly the distinction I was trying to establish. The session ID itself is not the ultimate security objective. The receiver is making a security-sensitive authorization decision for a Mach IPC request. From the kernel-provided audit token, it validates the sender process identity, including PID and code-signing identity, and we were considering the ASID/session state as an additional check that the requesting principal had not become stale due to logout, session termination, or a similar transition before authority is exercised. The property we actually need is: At the point the receiver authorizes the request, establish that the request still belongs to the same live, authenticated sender principal that originated the Mach message, and fail closed if that authority has become stale or invalid. We do not need SessionGetInfo specifically if another supported macOS design pattern provides a stronger way to establish that property. Given the race you described, would you recommend anchoring this primarily to the lifetime and identity of the sender process instead of trying to independently prove audit-session liveness? For example, if the receiver validates the kernel-provided audit token, sender PID, code-signing identity, and that the originating process is still alive at the authorization point, is there a supported mechanism or pattern you would recommend to prevent stale/replayed authority across logout, process exit/restart, PID reuse, or other principal changes? I’m specifically trying to avoid relying on an inherently racy session lookup if macOS provides a stronger process- or connection-bound primitive.