Computer Use does not yield control to human input injected through macOS RDP

What issue are you seeing?

Feedback ID: 019fe3bc-7844-7823-b26d-a3885688e747

On macOS, Codex Computer Use can cause a remote user to lose effective control of the desktop when the same graphical session is accessed through NuoRDS/RDP.

The RDP client sends the user’s mouse and keyboard actions to NuoRDS. NuoRDS translates those actions into synthesized macOS input. Codex Computer Use independently generates mouse, keyboard, click, and focus actions in the same session through macOS Accessibility.

The investigation did not establish that both products use the same low-level input API. However, both ultimately generate competing input in the same macOS GUI session.

While Computer Use was active:

• RDP clicks and keystrokes appeared ineffective.
• The display and clock continued updating normally.
• Reconnecting with a fresh RDP profile did not restore control.
• NuoRDS remained healthy.
• Secure Event Input was not active.
• Restarting NuoRDS did not resolve the condition.

Pausing only the Codex process tree immediately restored RDP control. The affected user independently confirmed that the Apple menu opened and normal input worked again. No reboot or logout was required.

This suggests that Computer Use does not recognize NuoRDS-generated remote input as a human takeover attempt, or it continues issuing UI actions after receiving that input. Codex should provide a supported way to detect remote human input and yield or pause Computer Use.

This issue can prevent a remote user from controlling the desktop or logging out. On usage-based managed services, that could also create unintended billing or overage risk.

One additional behavior affects the temporary workaround: pausing Codex with SIGSTOP preserves its process state. However, if the stopped Codex window remains frontmost, it cannot process menu actions. Clicking the Apple menu may appear to do nothing until focus moves to Finder. This is a side effect of the workaround, not the original failure.

What steps can reproduce the bug?

Conditions:

• Physical Mac running macOS
• NuoRDS installed and configured for remote desktop access
• Standard macOS user account
• Codex app with Computer Use enabled

Steps:

1. Connect to the Mac through an RDP client using NuoRDS.
2. Sign in to the standard user account.
3. Open the Codex app within the remote session.
4. Start a task that activates Computer Use.
5. While Computer Use is running, attempt to control the Mac through RDP.

What is the expected behavior?

The RDP session remains connected and the display continues updating, but the user’s clicks and keystrokes appear ineffective while Computer Use continues generating input.

Additional information

From an administrator account, I paused only the affected user’s Codex processes with SIGSTOP. Manual RDP control returned immediately without restarting or logging out of the Mac.

If the suspended Codex window remains active, it appears frozen and cannot process menu actions. The Apple menu may also appear unresponsive because the stopped application still owns the menu bar. Switching focus to Finder or the desktop restores normal menu interaction.

Resuming the Codex processes with SIGCONT causes the remote user to lose effective control again while Computer Use remains active. Control returns after Computer Use finishes or is paused.

OpenAI’s Computer Use documentation describes a user takeover control. In this RDP configuration, however, the user cannot reliably interrupt Computer Use. This suggests that Codex may not recognize input synthesized through NuoRDS as human takeover input.