Windows Codex App: in-app browser visibility.set(true) succeeds but visibility.get() remains false

Open 💬 3 comments Opened May 22, 2026 by NemuKei

Summary

On Windows Codex App, the Codex in-app browser visibility capability appears to accept set(true), but visibility.get() continues to report false. Navigation and page inspection work, so the issue appears isolated to the visibility state / presentation confirmation path.

This matters because an agent can open and inspect a page in the in-app browser, but cannot honestly confirm that the page has been shown to the user.

Environment

  • OS: Windows
  • Codex App package: OpenAI.Codex_26.519.2736.0_x64__2p2nqsd0c76g0
  • codex command: C:\Program Files\WindowsApps\OpenAI.Codex_26.519.2736.0_x64__2p2nqsd0c76g0\app\resources\codex.exe
  • codex version from command resolution: 0.133.0.0
  • Browser plugin: 26.519.22136
  • Chrome plugin: 26.519.22136
  • Browser backend visible to the runtime: Codex In-app Browser with browser capabilities visibility and viewport
  • Chrome Extension backend is also visible in the same runtime

Previous local observation before update:

  • Codex App package: OpenAI.Codex_26.519.2081.0_x64__2p2nqsd0c76g0
  • Browser plugin: 26.519.21041
  • Same behavior observed

Reproduction steps

Using the bundled Browser plugin runtime for the in-app browser:

  1. Bootstrap browser-client.mjs and select the iab browser.
  2. Get the visibility capability: await browser.capabilities.get("visibility").
  3. Call await visibility.get().
  4. Call await visibility.set(true).
  5. Poll await visibility.get() at 0ms, 250ms, 1000ms, 2500ms, and 5000ms.
  6. Open a local test page in a new in-app browser tab, e.g. http://127.0.0.1:<port>/p7-08-updated-navigation.
  7. Confirm page load by title, DOM snapshot, and local HTTP request log.
  8. Call await visibility.get() again after navigation.

Expected behavior

After visibility.set(true) returns successfully, the in-app browser should become visible to the user, and visibility.get() should return true, or the API should return an error / status that lets the agent know presentation failed.

Actual behavior

  • visibility.set(true) returns successfully.
  • visibility.get() remains false at all sampled times:
  • before set(true): false
  • 0ms: false
  • 250ms: false
  • 1000ms: false
  • 2500ms: false
  • 5000ms: false
  • after navigation: false
  • visibility.set(false) also returns successfully.
  • Navigation itself works:
  • tab.goto(...) succeeds
  • waitForLoadState({ state: "load" }) succeeds
  • title is readable
  • DOM snapshot contains the expected heading and body text
  • local HTTP server receives the expected GET request

Impact

The agent can navigate and inspect the in-app browser, but cannot verify that the user can see it. For user-facing GUI checks, this forces the agent to avoid saying it has "shown" the page and instead ask the user to open the in-app browser manually via toolbar / URL click / manual navigation / keyboard shortcut.

Notes

I searched for related reports and found issues about Browser Use / in-app browser startup, handshake, and deferred tool discovery, but did not find an exact match for visibility.set(true) succeeding while visibility.get() remains false.

No page content, credentials, cookies, or session data are included in this report.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗