In-app browser: locator.fill fails with "virtual clipboard is not installed" on normal text inputs

Open 💬 0 comments Opened May 17, 2026 by Wyndace

What happened?

In the Codex Desktop in-app browser (iab backend), tab.playwright.locator(...).fill(...) can fail with:

Browser Use encountered an error interacting with this webpage's clipboard: Browser Use virtual clipboard is not installed
locator.fill failed for selector ...

After more testing, the failure pattern looks tied to page-to-page navigation within the same in-app browser pane.

Expected behavior

locator.fill(...) should continue to work on normal text inputs after navigating between pages in the same in-app browser pane.

Actual behavior

A pattern that repeatedly showed up during testing on GitHub:

  • On one page, repeated fill(...) calls can work normally.
  • If text has already been entered on page A, then the tab navigates to page B in the same in-app browser pane, fill(...) on page B may fail with virtual clipboard is not installed.
  • If page B is only visited without entering text there, then going back to page A can still allow fill(...) to keep working on page A.

So the failure is not simply "fill is always broken". It appears flaky and state-dependent, with navigation between pages in the same pane being an important trigger.

Repro pattern

This is the clearest pattern I was able to reproduce on github.com:

  1. Open Codex Desktop.
  2. Open the in-app browser.
  3. Connect to the selected iab tab.
  4. Go to https://github.com/login.
  5. Wait for the page to load and settle.
  6. Successfully fill(...) the username and password fields.
  7. Navigate in the same tab to https://github.com/signup.
  8. Wait for that page to load and settle.
  9. Try fill(...) the email field.
  10. Observe that it may fail with Browser Use virtual clipboard is not installed.

A representative snippet:

if (!globalThis.agent) {
  const { setupBrowserRuntime } = await import('/Users/<user>/.codex/plugins/cache/openai-bundled/browser/0.1.0-alpha2/scripts/browser-client.mjs');
  await setupBrowserRuntime({ globals: globalThis });
}
if (!globalThis.browser) {
  globalThis.browser = await agent.browsers.get('iab');
}

const page = await browser.tabs.selected().catch(() => browser.tabs.new());
await page.goto('https://github.com/login');
await page.playwright.waitForLoadState({ state: 'load', timeoutMs: 20000 }).catch(() => {});
await new Promise(r => setTimeout(r, 5000));

await page.playwright.locator('input[name="login"], input[autocomplete="username"], input[type="text"]').first().fill('alpha-random');
await page.playwright.locator('input[type="password"]').first().fill('beta-random');

await page.goto('https://github.com/signup');
await page.playwright.waitForLoadState({ state: 'load', timeoutMs: 20000 }).catch(() => {});
await new Promise(r => setTimeout(r, 5000));

await page.playwright.locator('input[type="email"], input[name="email"]').first().fill('gamma@example.com');

Observed failure when the bug reproduces:

Browser Use encountered an error interacting with this webpage's clipboard: Browser Use virtual clipboard is not installed
locator.fill failed for selector input[type="email"], input[name="email"] >> nth=0

Important nuance

This behavior is flaky rather than perfectly deterministic.

During testing, I also saw cases where:

  • repeated fill(...) calls on the same page both succeeded,
  • or visiting another page without entering text there and then going back allowed fill(...) to continue working on the original page.

So the issue is best described as a state-dependent / navigation-related fill(...) failure in the in-app browser backend, not as a strict one-shot rule.

Environment

  • Codex Desktop app
  • in-app browser backend: iab
  • Browser plugin path observed locally: openai-bundled/browser/0.1.0-alpha2
  • macOS

View original on GitHub ↗