[macOS][Computer Use] Secure Event Input remains active after screen unlock and app quit until logout

What version of the Codex App are you using (From “About Codex” dialog)?

26.818.41509 (build 6962)

What subscription do you have?

Unknown (not available from local diagnostics)

What platform is your computer?

Darwin 25.6.0 arm64 arm (macOS 26.6.1, Apple Silicon)

What issue are you seeing?

After a Locked Computer Use authorization attempt during screen unlock, Codex became the owner of macOS session-wide Secure Event Input. Secure Event Input then remained enabled while an ordinary, non-secure application was active, causing a CGEventTap-based keyboard tool that intentionally fails closed during Secure Event Input to stop transforming keys. The behavior was confirmed in a new TextEdit document, not in a password or other secure field.

Fully quitting Codex did not clear the state. kCGSSessionSecureInputPID continued to identify the former Codex process after that process had exited. Only logging out of the macOS GUI session and logging back in cleared Secure Event Input. After logging back in, Codex could be open normally while Secure Event Input remained disabled, so this does not appear to be an intentional persistent Codex state.

Sanitized observation timeline:

21:23:40.794  An independent monitor detects Secure Event Input disabled.
21:23:41.149  WindowServer records the ChatGPT/Codex main process as frontmost.
21:23:41.463  An independent monitor detects Secure Event Input enabled;
              kCGSSessionSecureInputPID resolves to that main process.
21:32:37.013  That Codex process exits.
After exit     Secure Event Input remains enabled and the owner property still
              identifies the now-dead Codex process.
After logout/login
              Secure Event Input is disabled and the owner property is absent.

What steps can reproduce the bug?

This has been observed once and may be timing-dependent:

1. Install/enable Codex Computer Use and its Locked Use authorization integration.
2. Run a session-level CGEventTap keyboard tool or a monitor for IsSecureEventInputEnabled().
3. With Locked Use enabled and its authorization rule registered, lock the Mac.
4. Unlock the screen and return to Codex.
5. Type in a normal TextEdit document. The keyboard tool no longer transforms input because its Secure Event Input safety gate is active, IsSecureEventInputEnabled() is true, and the PID reported by ioreg as kCGSSessionSecureInputPID resolves to the ChatGPT/Codex main process (com.openai.codex).
6. Fully quit Codex and verify that its main process has exited. Secure Event Input remains enabled and the owner property still identifies the dead PID.
7. Log out of the GUI session and log back in. Secure Event Input is finally cleared and the event-tap tool works again.

What is the expected behavior?

If Codex or one of its bundled components enables Secure Event Input, it should release that state when secure entry is no longer required and when the app exits. A dead Codex PID must not remain the session-wide Secure Event Input owner and block unrelated keyboard tools until logout.

Apple's archived Technical Note TN2150 says applications should disable Secure Event Input when it is no longer needed or the application becomes inactive:
https://developer.apple.com/library/archive/technotes/tn2150/_index.html

Additional information

The installed components were not on the same version:

• Codex App: 26.818.41509 (build 6962)
• Bundled Computer Use app: 26.819.1000816
• System authorization plug-in: 26.812.1000717

The Computer Use installer reported the authorization plug-in as not-installed, while the system.login.screensaver authorization rule still referenced com.openai.sky.CUAService.AuthorizationPlugin.remote. Around the affected unlock, SecurityAgentHelper recorded a library-validation error for the older authorization plug-in and the plug-in authorization socket returned DENY. These facts may be related to the trigger, but the causal connection to Secure Event Input is not yet proven.

The exact failure boundary is also not yet proven: Codex/Electron may have left an unbalanced Secure Event Input enable during foreground restoration, macOS/WindowServer may have failed to clean up the state after process exit, or both may be involved.

Possibly related issues with different symptoms:

• #40226 — Locked Use authorization plug-in leaves the login keychain locked
• #39534 — Locked Use plug-in rejection during screen unlock
• #36868 — Computer Use keyboard event lifecycle issue
• #36958 — Computer Use activity continuing after Codex closes

No raw logs, account identifiers, local file paths, device names, or user data are included in this report. Sanitized diagnostic details can be provided if needed.