[Browser / Computer Use] Support timed holds for mouse buttons and keyboard keys

What variant of Codex are you using?

Codex desktop app on Windows; in-app browser through the unified Computer Use interface.

What feature would you like to see?

Please expose bounded, duration-controlled holds for both mouse buttons and keyboard keys. Some interfaces require keeping an input pressed across multiple animation frames: a keyboard arrow for movement, an on-screen accelerator, or a press-and-hold control. Repeated clicks or discrete key taps are not equivalent to a continuous hold.

Requested behavior

• Keyboard: press a specified key, keep it down for a requested duration such as 1000 ms, then release it.
• Mouse: press a specified mouse button on a target, keep it down at that location for a requested duration, then release it. This should not require moving the pointer or turning the gesture into a drag.
• Preserve existing short-press/click behavior when no hold duration is requested.
• Execute the entire timed hold within the input backend, rather than requiring a model/tool round trip between down and up.
• Validate duration limits and release owned inputs on cancellation, failure, navigation, target loss, or session teardown. Report unsupported backends explicitly.

Separate down/up primitives with guaranteed cleanup, or a bounded durationMs option on the existing input operations, could provide these semantics. These are proposed interfaces, not methods currently exposed in the tested session. Overlapping held keys/buttons would also help workflows such as accelerating while steering, but single-input timed holds would already solve a useful part of the problem.

Practical use case

While testing the parking level (Level 15) of the public Neal.fun "I'm Not a Robot" game, the agent could identify the vehicle, parking spot, arrow keys, and on-screen controls but could not request sustained input. The user identified a long press as the required interaction. Short keyboard presses, clicks on the accelerator, and a drag within that button produced no visible vehicle movement.

This is a request for a general input capability, applicable to games, simulations, and ordinary press-and-hold UI controls.

Evidence and current interface

The session's documented pressKey(key: string) signature has no hold duration or separate down/up methods. The documented click options likewise have no hold duration. A locator's timeoutMs setting is an operation timeout, not a duration to hold input.

On an independent local HTML page that logs arrow-key events and samples held state with requestAnimationFrame, three supported pressKey('Up') calls produced:

All six keyboard events reported isTrusted=true and repeat=false. The animation loop observed a held key for only two frames across the three calls; the sample object moved less than one CSS pixel in total. These are session observations, not guaranteed timings.

Mouse hold timing has not been measured. The mouse request is supported by the missing duration option and the concrete need to hold an on-screen control; the keyboard measurements above should not be interpreted as mouse measurements. The local reproduction also does not prove that short input duration is the only possible cause of the game's behavior.

Acceptance criteria

For both a keyboard key and a mouse button, a requested 1000 ms hold should keep the input pressed across animation frames until it is released approximately 1000 ms later, with a documented timing tolerance. Test default short inputs, configured holds, cancellation, and target/navigation cleanup. These are proposed checks; no new implementation has been built or validated here.

Additional information

• Observed on 2026-09-09, on Windows with the Codex in-app browser.
• Unified Computer Use plugin bundle: 26.901.51231.
• Installed packages: @oai/cua 0.2.4 and @oai/browser-desktop 0.1.1.
• Exact desktop app version was not captured. Package versions above are not the desktop app version.
• Related: #34316 requests keyboard holds for a macOS emulator. This report explicitly covers both mouse-button holds and keyboard holds in the Windows browser interaction surface; maintainers can merge or cross-reference it as appropriate.
• Original public use case: https://neal.fun/not-a-robot/

Start with the documented pressKey and click operations in the unified Computer Use input backend, then trace cancellation, navigation, target-loss, and session-teardown handling. Use the stated acceptance checks to verify bounded keyboard and mouse holds, preserved short presses, timing tolerance, cleanup, and explicit unsupported-backend reporting.