Codex Desktop in-app Browser Use runtime reports virtual clipboard missing until bootstrapped from Chrome runtime

Resolved 💬 2 comments Opened May 22, 2026 by JCEY289 Closed Aug 4, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Environment

  • OS: Windows
  • Codex Desktop
  • In-app browser / Browser Use
  • Bundled browser plugin version observed: 26.519.31651
  • Bundled browser-use plugin version observed: 0.1.0-alpha2

Problem

The in-app browser Browser Use runtime can enter an incomplete state where text input requiring the virtual clipboard fails with:

Browser Use virtual clipboard is not installed

This breaks non-ASCII input, for example Chinese text in web forms. ASCII-only input such as dates or short values can still work, which makes the failure look application-specific at first.

Evidence

The in-app browser related bundled plugin directories existed, but the expected runtime entrypoint was missing:

<codex-home>\plugins\cache\openai-bundled\browser\26.519.31651\scripts\browser-client.mjs
<codex-home>\plugins\cache\openai-bundled\browser-use\0.1.0-alpha2\scripts\browser-client.mjs

The complete runtime entrypoint did exist under the bundled Chrome plugin:

<codex-home>\plugins\cache\openai-bundled\chrome\26.519.31651\scripts\browser-client.mjs

Before bootstrapping from the complete runtime, calls such as Browser Use fill, type, cua.type, or tab.clipboard.writeText failed with the virtual clipboard error.

After manually importing and running setupBrowserRuntime from the complete bundled Chrome runtime, the same in-app browser tab could successfully run:

tab.clipboard.writeText("Chinese text test")
tab.clipboard.readText()
locator("textarea").fill("Chinese text test")

Expected behavior

The in-app browser should load a complete Browser Use runtime by default, and virtual clipboard support should be available without manually bootstrapping from the Chrome plugin runtime.

Actual behavior

The default in-app Browser Use path can initialize without working virtual clipboard support. Non-ASCII input then fails with Browser Use virtual clipboard is not installed.

Impact

Authenticated browser workflows that need non-ASCII form input become unreliable. This is especially confusing because ASCII-only fields still work, so the failure appears only when entering localized text.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #23208

Powered by Codex Action

JCEY289 · 3 months ago

Thanks for the duplicate check. I reviewed #23208.

This does look closely related and may be the same underlying in-app browser virtual clipboard failure. My case adds two pieces of diagnostic information that may be useful:

  • Platform: Windows, while #23208 reports macOS.
  • In my local bundled plugin cache, the in-app browser runtime entrypoint was missing at:

<codex-home>\plugins\cache\openai-bundled\browser\26.519.31651\scripts\browser-client.mjs
and:
<codex-home>\plugins\cache\openai-bundled\browser-use\0.1.0-alpha2\scripts\browser-client.mjs

The complete runtime did exist at:

<codex-home>\plugins\cache\openai-bundled\chrome\26.519.31651\scripts\browser-client.mjs

After manually bootstrapping setupBrowserRuntime from that complete bundled Chrome runtime, the same in-app browser tab could successfully use tab.clipboard.writeText/readText and locator.fill(...) with non-ASCII text.

So I agree this may be a duplicate of #23208, but this issue documents a Windows variant where the failure appears tied to an incomplete or wrong bundled runtime being used. If maintainers prefer tracking this entirely under #23208, I am happy to close this issue as a duplicate.