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.