›_ Codex Issues
Codex Issues / #25788

Locked Computer Use fallback typed into macOS login password field

Open 💬 0 comments Opened Jun 2, 2026 by Co5mos

Summary

When using Codex remote control from iOS to operate a connected Mac, Computer Use works while the Mac is unlocked. With Locked Computer Use enabled, the same workflow can fail to locate the target app/window while the Mac is locked, then fall back to open / osascript keyboard automation. In my reproduction, that fallback input was sent to the macOS login password field instead of the target app, while Codex reported success.

This looks related to existing locked-use failures such as #24013 and #24086, but the distinct issue here is the unsafe fallback / false-success behavior after Computer Use cannot verify the target window.

Environment

  • Codex desktop app: 26.527.60818
  • Computer Use helper/plugin build: 799
  • macOS: 26.5 / build 25F71
  • Remote client: ChatGPT / Codex remote from iPhone, shown in Codex Connections as iOS 26.3.1 iPhone
  • Target app: Sublime Text
  • Computer Use settings:
  • Any app control enabled
  • Locked operation / Locked Computer Use enabled
  • Computer Use authorization plug-in installed at /Library/Security/SecurityAgentPlugins/CodexComputerUseAuthorizationPlugin.bundle
  • Authorization plug-in bundle id: com.openai.sky.CUAService.AuthorizationPlugin

Reproduction

  1. On the Mac, enable Codex remote control for the iPhone in Settings > Connections.
  2. Enable Computer Use and Locked operation / Locked Computer Use in Settings > Computer Use.
  3. From the iPhone remote Codex session, ask Codex to open Sublime Text and write test.
  4. While the Mac is unlocked, Computer Use successfully writes test into Sublime Text.
  5. Lock the Mac.
  6. From the same iPhone remote Codex session, ask Codex to append test666 in Sublime Text.
  7. Codex attempts to inspect Sublime with Computer Use but cannot locate the Sublime window/app handle.
  8. Codex then falls back to commands similar to:
  • open -a "Sublime Text"
  • osascript ... tell application "System Events" ... keystroke ...
  1. Codex reports that it appended/wrote test666.

Actual behavior

The text was not written into Sublime Text. It was typed into the macOS login password field on the lock screen.

Codex still reported success after the fallback automation.

Expected behavior

When the Mac is locked, if Computer Use cannot verify that it has reached the intended target app/window, Codex should stop and report failure.

It should not send generic keyboard input via shell / AppleScript / System Events while the visible/active UI is the macOS login screen, especially when the target app has not been confirmed.

Impact

This is a safety and reliability issue:

  • Text intended for a desktop application can be sent to the macOS login password field.
  • The task can falsely report success even though the input went to the wrong UI.
  • If a user asks Codex to type sensitive content while the Mac is locked, that content may be entered into an unintended authentication UI.

Notes

A prompt-level workaround is to explicitly forbid fallback automation, for example:

Only use Computer Use to operate Sublime Text. First read the Sublime window state. If Computer Use cannot see Sublime, stop immediately. Do not use open, osascript, AppleScript, shell commands, System Events, or keyboard automation fallback.

Screenshots of the Codex transcript and settings are available if useful.

View original on GitHub ↗