Summary
On macOS 26.5.2 (25F84) with FileVault on and the Codex/ChatGPT Locked Use feature active (the CodexComputerUseAuthorizationPlugin is installed under /Library/Security/SecurityAgentPlugins/), the login keychain enters a multi-hour master-key decode lockout after a normal screen-lock cycle. All existing keychain item reads fail silently with CSSMERR_CSP_INVALID_DATA / OSStatus -25337 (errSecInteractionNotAllowed) even though securityd reports the keychain as "unlocked". Touch ID unlock does not recover the keybag; a later unlock with a typed password does.
This is an independent confirmation of #35553 with a fully instrumented timeline, plus one additional data point: rebooting does not remove the trigger — the guardian restarts and can re-arm the lockout at the next screen lock.
Environment
- macOS 26.5.2 (build 25F84), Apple Silicon, FileVault: On
/Library/Security/SecurityAgentPlugins/CodexComputerUseAuthorizationPlugin.bundle installed 2026-06-21- ChatGPT desktop app 26.930.x, Codex CLI 0.157.0, Codex Computer Use (
SkyComputerUseService + CUALockScreenGuardian) active
- Affected consumers observed: VS Code (Electron
safeStorage / secret:// store) and Claude Code (stores credentials in login keychain) — both are victims, not causes
Symptom
- Every VS Code window start logged
Got 0 sessions from the GitHub Authentication extension → forced device-flow re-login each launch; Copilot Chat showed "GitHub login failed"
- Claude Code provider models list returned
Count: 0 (same keychain-backed credentials)
- No keychain ACL prompt ever appeared — reads just failed silently
- Writes succeeded throughout (new keychain items encrypted fine); only reads of items stored before the onset failed
security CLI reads from third-party binaries hung on the ACL prompt path as usual; the failure was at the keychain master-key decode layer, not per-item ACL
Timeline (local time, KST)
| Time |
Event |
| Day 1 11:48 |
Healthy baseline: VS Code reads Got 4 verified sessions in all windows |
| Day 1 17:42:56 |
CUALockScreenGuardian process starts |
| Day 1 21:00–21:11 |
coreautha refreshes Touch ID screen-lock assertions every ~54 s (Locked Use active); shield-window/accountd events at 21:11:21–24 |
| Day 1 21:11:24 |
First CSSMERR_CSP_INVALID_DATA + MacOS error: -25337 in securityd logs. Pattern: securityd logs is unlocked; decoding for makeUnlocked() then the CSP failure — i.e. keychain marked unlocked but master key undecodable |
| Day 1 21:11 → Day 2 11:42 |
Decode failures continue at 1–2 min intervals (~100–250 per hour, overnight). Every VS Code start reads 0 sessions; Claude models Count: 0 |
| Day 2 09:54–11:49 |
loginwindow repeatedly logs "Keybag is locked, setting promptForPassword = YES" at each unlock — Touch ID unlocks do not take keybag effect |
| Day 2 11:40:56 |
User unlocks with typed password → last CSP error at 11:42:30 → decode healthy from then on |
| Day 2 11:47 |
Claude Code credentials rewritten successfully (keychain writes + reads working again) |
| securityd |
never restarted during the whole incident — the bad state persisted in-place for ~14.5 h |
Recovery
- Typed-password unlock at 11:40 recovered decode without any reboot (last CSP error 11:42:30, zero after).
- A reboot was performed afterward (13:06). Post-reboot verification: securityd CSP errors 0, loginwindow logs
keybag already unlocked, VS Code reads Got 4 verified sessions in all windows with no re-login, Claude models Count: 10.
- However, the trigger came back with the apps:
SkyComputerUseService restarts on ChatGPT launch, and the guardian re-arming Touch ID lock assertions is the same condition that preceded the onset. The next screen lock could re-trigger the lockout.
What was ruled out
- VS Code binary: Gatekeeper/notarization OK, satisfies its Designated Requirement
- Login keychain: no auto-lock timeout, non-empty password (not a "blank password keychain" case)
- The encryption key item itself unchanged since 2023 — the failure is master-key decoding, not per-item key drift
- The stored secret blob is well-formed (Electron safeStorage
v10) — inaccessible, not corrupted
- OCSP/revocation noise from a local PAC proxy and a one-off authd notarization-check error were secondary at most
Suggested mitigations / asks
- Codex/ChatGPT side: when Locked Use is enabled, ensure the screen-unlock path actually unlocks the FileVault keybag (or avoid holding screen-lock assertions that leave the keybag locked while the session is usable). Detect
CSSMERR_CSP_INVALID_DATA storms and surface a user-visible warning instead of letting apps silently lose keychain access.
- Docs: state that on FileVault Macs, Locked Use + Touch ID unlock can leave the login keychain undecodable for hours, and that a typed-password unlock recovers it.
- Longer term: consider not installing the SecurityAgentPlugin / guardian behavior when FileVault + Locked Use combination is known-bad on 26.5.x.
Workarounds for users today
- Unlock the screen with a typed password (not Touch ID) while Locked Use is enabled
- Or disable Locked Use / quit Codex Computer Use
- If stuck: typed-password unlock, or reboot; affected apps then read keychain normally again
Related
Summary
On macOS 26.5.2 (25F84) with FileVault on and the Codex/ChatGPT Locked Use feature active (the
CodexComputerUseAuthorizationPluginis installed under/Library/Security/SecurityAgentPlugins/), the login keychain enters a multi-hour master-key decode lockout after a normal screen-lock cycle. All existing keychain item reads fail silently withCSSMERR_CSP_INVALID_DATA/ OSStatus-25337(errSecInteractionNotAllowed) even though securityd reports the keychain as "unlocked". Touch ID unlock does not recover the keybag; a later unlock with a typed password does.This is an independent confirmation of #35553 with a fully instrumented timeline, plus one additional data point: rebooting does not remove the trigger — the guardian restarts and can re-arm the lockout at the next screen lock.
Environment
/Library/Security/SecurityAgentPlugins/CodexComputerUseAuthorizationPlugin.bundleinstalled 2026-06-21SkyComputerUseService+CUALockScreenGuardian) activesafeStorage/secret://store) and Claude Code (stores credentials in login keychain) — both are victims, not causesSymptom
Got 0 sessionsfrom the GitHub Authentication extension → forced device-flow re-login each launch; Copilot Chat showed "GitHub login failed"Count: 0(same keychain-backed credentials)securityCLI reads from third-party binaries hung on the ACL prompt path as usual; the failure was at the keychain master-key decode layer, not per-item ACLTimeline (local time, KST)
Got 4 verified sessionsin all windowsCUALockScreenGuardianprocess startscoreautharefreshes Touch ID screen-lock assertions every ~54 s (Locked Use active); shield-window/accountd events at 21:11:21–24CSSMERR_CSP_INVALID_DATA+MacOS error: -25337in securityd logs. Pattern: securityd logsis unlocked; decoding for makeUnlocked()then the CSP failure — i.e. keychain marked unlocked but master key undecodableCount: 0Recovery
keybag already unlocked, VS Code readsGot 4 verified sessionsin all windows with no re-login, Claude modelsCount: 10.SkyComputerUseServicerestarts on ChatGPT launch, and the guardian re-arming Touch ID lock assertions is the same condition that preceded the onset. The next screen lock could re-trigger the lockout.What was ruled out
v10) — inaccessible, not corruptedSuggested mitigations / asks
CSSMERR_CSP_INVALID_DATAstorms and surface a user-visible warning instead of letting apps silently lose keychain access.Workarounds for users today
Related
CSSMERR_CSP_INVALID_DATAsymptom seen from the Claude Code side