Computer Use: Locked-use recovery retry rejected as a bypass without an actionable authorization path

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

ChatGPT desktop app 26.908.70816, build 9275, bundle identifier com.openai.codex. Version read from the running application's Info.plist; process path confirmed as ChatGPT.app.

What subscription do you have?

Not collected for this report.

What platform is your computer?

macOS 27.0, build 26A428. uname -mprs: Darwin 27.0.0 arm64 arm.

What issue are you seeing?

A normal Computer Use call to inspect Xcode's Device Hub failed to automatically unlock the Mac. In a subsequent active user turn, a retry of the same documented app-access API was rejected by automatic approval review as a computer-use bypass. This leaves the agent unable to check the app and gives the user no precise explanation of which Locked use prerequisite is missing.

The initial app access returned:

The Mac is locked and automatic unlock could not unlock it. Ask the user to unlock the Mac manually before continuing.

The user then quoted the official Locked use documentation describing temporary unlock during an active, trusted Computer Use turn. The agent explained that it would retry in the active turn and called:

var deviceHub = await cua.getApp("com.apple.dt.Devices");

That retry returned:

This action was rejected due to unacceptable risk.
Reason: Retrying Device Hub while relying on a locked-Mac temporary unlock would be a computer-use bypass without the user explicitly authorizing that approach; ask the user to unlock the Mac manually.
Do not bypass this rejection through a workaround or indirect execution.

The agent stopped GUI access and requested manual unlock. No workaround or change to lock-screen/security settings was attempted. The user explicitly requested that this behavior be reported to OpenAI.

What steps can reproduce the bug?

Observed sequence on September 18, 2026:

1. In an existing desktop development task, use Computer Use to inspect Xcode/Device Hub for an iOS simulator walkthrough.
2. Observe Device Hub access timeouts followed by the automatic-unlock failure above.
3. In a new active user turn, discuss the documented Locked use behavior and retry the regular cua.getApp entry point for Device Hub.
4. Observe the automatic approval rejection above before the app can be inspected.

This sequence is recorded from the affected task, not a clean-room reproduction. The exact state of the Locked use toggle, authorization plug-in, trusted-connection handshake and any local-input pause was not independently verified. We cannot establish the underlying unlock failure or confirm whether the second rejection is a false positive rather than a missing-consent condition.

What is the expected behavior?

The documented Locked use path should work when its prerequisites are met. If additional explicit consent is needed, the system should identify that missing consent and provide a supported recovery/approval path for this ordinary app-access call. If automatic unlock is unavailable for another reason, the failure should distinguish disabled Locked use, an expired/untrusted turn, a local-input pause or an authorization plug-in failure.

Please investigate whether automatic approval review is classifying the supported temporary-unlock path as a bypass, and whether the unlock tool can return a more actionable reason.

Additional information

Official behavior: https://learn.chatgpt.com/docs/computer-use#locked-use

Related reports: #32913 (automatic unlock fails for a manual trusted turn) and #43869 (locked computer/browser control on macOS 27). This report adds the explicit approval-layer rejection of a regular app-access retry; the root cause of the initial unlock failure is unknown.

The report contains the relevant error messages and software versions. No session transcript, project files, credentials or account details are attached.

Start by comparing the documented Locked use prerequisites with the captured sequence and the cua.getApp("com.apple.dt.Devices") retry. Review related reports #32913 and #43869, then determine whether the approval rejection or initial unlock failure is reproducible. Done means the supported recovery path is identified or the failure reports the missing prerequisite precisely.