Codex desktop intermittently reports “Mac is locked” while user reports it remains unlocked, after browser CDP timeouts

Intermittent false “Mac is locked” error during browser/computer use

Environment

• ChatGPT desktop / Codex, bundle com.openai.codex
• Version 26.901.51231, build 8109 (read from installed app metadata)
• macOS 26.6.2, Apple silicon / arm64 (read locally)
• Browser: Google Chrome through the Codex browser extension
• Observed: 7 September 2026, Asia/Kuala_Lumpur timezone

Problem

During an active, previously working browser-use task, the runtime reported that the Mac was locked. The user states the Mac was unlocked throughout, and reports encountering this repeatedly with both browser use and computer use.

The unlocked-at-failure state is user-reported: the agent did not capture an independent OS lock-state snapshot at the moment of failure.

Observed sequence

1. Browser UI reads, navigation and clicks worked repeatedly during the task.
2. A post-specific DOM read failed with Timed out after 3000ms waiting for CDP command Runtime.evaluate.
3. A subsequent accessibility-state read failed with Timed out after 10000ms waiting for CDP command Emulation.setFocusEmulationEnabled.
4. Calling cua.getState() returned: The Mac is locked and automatic unlock could not unlock it. Ask the user to unlock the Mac manually before continuing.
5. The task stopped and relayed that error to the user.
6. The user disputed the lock diagnosis and requested a retry.
7. A later cua.getState() succeeded and returned normal app/browser inventory. A newly created Chrome task tab supported reading and bookmark removal again. No agent-initiated restart, unlock or permission change was performed.

Task tabs from the ended turn were no longer in the later inventory. Their closure may be ordinary task-tab lifecycle, so it is not evidence of the root cause.

Expected behavior

On an unlocked Mac, browser/computer use should continue or report its actual connection/focus/state-acquisition failure. A lock-specific error should be backed by a current lock-state check. Transient browser timeouts should not be presented as a confirmed lock state without evidence.

Impact and reproduction limits

The misleading message interrupts otherwise authorised work and asks for an unnecessary manual unlock. The user reports multiple occurrences. One failure/recovery sequence is captured here; there is no deterministic reproducer or confirmed root cause yet. Browser use was exercised directly in this run; recurrence in general computer use is user-reported.

Suggested investigation: correlate CDP timeout handling, desktop accessibility/focus state, and the lock-state/guarded-unlock error path. A stale or misclassified state is a hypothesis, not an established diagnosis. Please expose which check produced the lock verdict and distinguish a missing/failed state read from an affirmative locked result.

Related reports checked

• https://github.com/openai/codex/issues/32396 — same generic automatic-unlock error, but reproducer actually locks the Mac.
• https://github.com/openai/codex/issues/32913 — failure from a trusted remote connection with an idle-locked Mac.
• https://github.com/openai/codex/issues/37946 — idle-lock and manual-lock paths behave differently.

These are adjacent reports, not confirmed duplicates of the false-lock condition here. No verified public fix for this exact condition was found in the targeted search.

A targeted search of this day's desktop text logs for the exact error and CDP operation names found no matches. No private page contents, account identifiers, credentials or full session logs are included in this report.

Trace the cua.getState() path and the CDP timeout, accessibility/focus, and guarded-unlock error handling described in the report. Use the recorded Runtime.evaluate and Emulation.setFocusEmulationEnabled failures as the starting scenario. Done means transient state-read failures are distinguished from an affirmative lock result and the user receives the actual failure state.