[macOS] Login Keychain replaced and Touch ID enrollments lost after restart with Locked Use plugin registered

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

The desktop logs show ChatGPT/Codex App 26.814.41407 (build 6720) active around the incident.

The app has since updated to 26.818.41509 (build 6962).

What platform is your computer?

• macOS 26.4.1 (25E253)
• Apple Silicon (arm64)
• FileVault enabled
• No MDM enrollment
• Codex Computer Use authorization plug-in: 0.1.0 (build 799)

What issue are you seeing?

After a restart, the macOS login Keychain had been replaced/moved aside, sign-in sessions were lost across unrelated applications, and all enrolled Touch ID fingerprints had disappeared.

Observed effects included:

• TeamViewer was signed out.
• OneDrive was signed out.
• Other Keychain-backed application sessions were unavailable.
• Touch ID reported zero enrolled fingerprint templates.
• The previous login Keychain existed as login_renamed_1.keychain-db.
• A new, much smaller login.keychain-db was subsequently created.
• The Mac login password had not been changed or reset.

Before the restart, macOS had also stopped playing video files. That symptom may be unrelated, but it preceded the restart after which the credential and Touch ID loss became visible.

Local forensic timeline

Times below are local time (UTC+09:30) on 2026-08-22:

| Time | Observation |
|---|---|
| 13:48 | Last interactive Codex agent/tool operation completed. |
| 17:30:31 | Background Codex app logged keyring.load start for service Codex MCP Credentials, followed by keyring.load no entry. |
| 17:31:56 | login_renamed_1.keychain-db was created according to APFS birth time. |
| 17:32:34 | The renamed Keychain file's modification completed. |
| 17:37 | macOS rebooted. |

A later reboot occurred on 2026-08-23. The replacement login.keychain-db has a birth time of 2026-08-23 10:21:47 local time.

The observed Codex Keychain read occurred approximately 85 seconds before the old login Keychain file appeared.

Codex activity checked

The relevant Codex session and local logs were reviewed with sensitive values redacted:

• No Codex agent/tool command referenced Keychain, Touch ID, security, bioutil, or ~/Library/Keychains.
• The last interactive tool operation was more than three hours before the Keychain event.
• Codex logs immediately before the event show item-level Keychain reads returning “no entry.”
• No corresponding keyring.save, keyring.delete, Keychain reset, or reported Keyring error was found before the event.
• Raw logs are not attached because they may contain authentication headers or other private data. Narrow redacted excerpts can be provided if requested.

This report therefore does not claim that the Codex agent intentionally executed a reset. It reports a close temporal correlation with the background desktop app and a potentially relevant lock-screen authorization integration.

Locked Use authorization state

The Codex authorization plug-in is currently present at:

/Library/Security/SecurityAgentPlugins/CodexComputerUseAuthorizationPlugin.bundle

Its version is 0.1.0, build 799.

A read-only check of system.login.screensaver shows the mechanisms in this order:

1. com.openai.sky.CUAService.AuthorizationPlugin.remote
2. use-login-window-ui

The custom authorization right invokes:

CodexComputerUseAuthorizationPlugin:allow

This is notable because build 799 and the same authorization mechanism appear in related Locked Use reports.

Other system checks

• APFS verification completed successfully.
• Disk SMART status is verified.
• The disk has substantial free space.
• The login password was unchanged.
• No direct shell/file operation capable of resetting the Keychain was found in the Codex session.

Steps to reproduce the bug

The failure has occurred once and is not reproducible on demand.

Conditions present:

1. macOS 26.4.1 on Apple Silicon with FileVault enabled.
2. Codex Desktop running in the background.
3. Codex Locked Use authorization plug-in build 799 installed and registered in system.login.screensaver.
4. Restart the Mac after the system begins exhibiting abnormal media playback behavior.
5. After login, observe application sign-outs, a replaced login Keychain, and no enrolled Touch ID fingerprints.

What is the expected behavior?

Codex Desktop and its Computer Use/Locked Use components must not:

• reset, replace, or move aside the user's login Keychain;
• interfere with the macOS keybag or Touch ID enrollment state;
• make unrelated applications lose their stored sessions;
• leave a third-party authorization mechanism able to destabilize normal local authentication.

If the Keychain, keybag, authorization plug-in, or login-window integration is unavailable, Codex should fail safely and fall back to the standard macOS login mechanism without modifying authentication state.

Related reports

• #35553 — Locked Use auth plug-in suspected in recurring macOS keybag/login-Keychain lockouts
• #39534 — same Codex app version; Locked Use plug-in blocks manual Touch ID unlock
• #24394 — Codex Computer Use auth plug-in breaks macOS lock-screen unlock
• #24013 — build 799 rejected by SecurityAgentHelper Library Validation
• #38691 — detached app-server repeatedly accesses macOS Keychain
• #36453 — app update signs user out and cannot write OAuth credentials
• #33287 — unrelated application sessions unavailable following Codex/Keychain interaction

Questions for maintainers

1. Can build 799 of the Locked Use authorization plug-in affect keybag or login-Keychain state during local unlock/restart?
2. Is there a known path where the app handles a “no entry” Keyring result by reinitializing credential or Keychain state?
3. Is the timing signature above known internally?
4. Which narrow, redacted logs or diagnostics would be most useful for process-level attribution?

No username, home-directory path, account identifier, token, cookie, session content, or raw database has been included.