[macOS] Chrome sessions become unavailable after Codex uses Chrome and Chrome is relaunched

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

26.707.72221 (build 5307)

What subscription do you have?

ChatGPT paid subscription (exact tier is not exposed in the diagnostics used for this report)

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Summary

On macOS, all authenticated website sessions in the user's normal Google Chrome profile became unavailable after Codex had used that Chrome instance and Chrome was later quit and relaunched. This has happened twice.

Chrome then displayed this banner:

Relaunch your browser to load your profile data and keep it encrypted

The accounts appeared signed out across multiple unrelated sites (including GitHub). The evidence suggests that the cookies may still exist but Chrome cannot decrypt them through macOS Keychain.

Observed system evidence

On every fresh Chrome launch during the second occurrence, macOS logged:

MacOS error: -25337
CSSMERR_CSP_OPERATION_AUTH_DENIED
error while checking integrity, denying access

Five consecutive Chrome launches produced the same Keychain denial.

The Chrome Safe Storage item still exists in the user's login keychain. Its Access Control tab says access is unrestricted / all applications may access it. However, a read-only security probe from the Codex environment returns exit code 51 (authorization failed) without reading or displaying the secret.

Chrome's code signature verifies successfully and Gatekeeper reports a notarized Developer ID application. No evidence of application tampering was found.

Chrome had auto-updated to 150.0.7871.124 while an older Chrome process remained open. The failure became visible only after that existing process was quit normally and the updated process started.

Codex correlation

Codex Chrome/Computer Use had interacted with the already-running visible Chrome instance earlier that evening. The local Codex session history contains no Chrome, Browser, or Computer Use action at the time Chrome quit. macOS recorded a clean user-initiated quit with exit status 0, not a crash.

In an earlier occurrence, Codex/Computer Use launched Chrome while the macOS login keychain was locked. Chrome then logged the same Safe Storage/metadata decryption failures and several sites required login again.

No Codex action that clears cookies, resets the profile, or deletes browser data was found.

What steps can reproduce the bug?

The issue has occurred twice but is not yet deterministic.

Second occurrence

1. Keep the user's normal signed-in Chrome profile running.
2. Allow Codex Chrome/Computer Use to interact with that already-running Chrome instance.
3. Chrome auto-updates in the background while the existing process remains open.
4. Quit Chrome normally.
5. Relaunch Chrome.
6. Observe the banner asking to relaunch to load profile data and keep it encrypted.
7. Observe that multiple unrelated websites are signed out.
8. Check macOS unified logs for the new Chrome PID; each launch reports OSStatus -25337, CSSMERR_CSP_OPERATION_AUTH_DENIED, and an integrity-check denial.

Earlier occurrence

1. Start a Codex task that launches/uses the user's normal Chrome profile while the macOS login keychain is locked or unavailable.
2. Chrome starts but cannot decrypt Safe Storage/profile metadata.
3. After the keychain becomes available, multiple site sessions still appear unavailable.

A full backup of the Chrome profile, login keychain, preferences, updater state, and Chrome application was made before attempting remediation. No Keychain item has been deleted or reset.

What is the expected behavior?

Codex should be able to use an existing Chrome session without changing the user's Keychain trust state or making the profile's encrypted cookies unavailable.

If the macOS login keychain or Chrome Safe Storage cannot be accessed, the Chrome integration should detect that condition and stop with a clear warning instead of launching or continuing against the user's normal profile.

After Codex finishes and Chrome is quit/relaunched, existing website sessions should remain readable and signed in.

Additional information

Versions and timing

• Codex App: 26.707.72221 (build 5307)
• Chrome: 150.0.7871.124
• Platform: Darwin 25.5.0 arm64 arm
• Chrome update installed before the second occurrence; the symptom appeared at the first relaunch afterward.

Related public issues reviewed

No exact duplicate was found for Chrome Safe Storage, mass logout, lost cookies, or encrypted profile data.

Possibly related but not duplicates:

• #24204: Codex sandbox cannot access macOS Keychain after an update.
• #28990: Codex App Keychain/OSStatus failure while generating a remote-control keypair.
• #32925 / #32951: recent Browser/Chrome plugin initialization regression; those fail before browser discovery and reports say the signed-in Chrome state remains intact.
• #28352: orphaned headless Chrome workers using temporary profiles.

Please investigate whether the Codex Chrome native host, Chrome plugin, or Computer Use launch path can interact badly with a locked/desynchronized macOS login keychain, especially across a Chrome auto-update and relaunch.

Sanitized unified-log excerpts and a precise local timeline are available if maintainers need them. No cookies, passwords, Keychain secrets, local usernames, account IDs, or private URLs are included in this report.