›_ Codex Issues
Codex Issues / #23962

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

Open 💬 3 comments Opened May 22, 2026 by NemuKei
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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 ↗

3 Comments

github-actions[bot] contributor · 3 months ago

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

  • #22678

Powered by Codex Action

NemuKei · 3 months ago

Additional Windows retest after Codex App restart / crash recovery.

Environment observed from this thread:

  • Codex Desktop package path resolves to OpenAI.Codex_26.519.11010.0_x64__2p2nqsd0c76g0.
  • OpenAI bundled Chrome plugin cache latest points to 26.519.81530.
  • agent.browsers.list() after setupBrowserRuntime({ globals: globalThis }) returns both the Chrome Extension backend and the Codex In-app Browser backend.
  • Chrome Extension backend is usable in the same thread: agent.browsers.get("extension") succeeds and extensionBrowser.user.openTabs() returns an array. I only checked the tab count; I did not print tab URLs, titles, page bodies, cookies, localStorage, or session data.

Current In-app Browser behavior:

  • agent.browsers.get("iab") succeeds.
  • The returned browser metadata advertises browser capabilities including visibility and viewport.
  • The actual object available in this thread has keys browserId, capabilities, tabs, and user; no callable visibility object was exposed on the returned browser object in this run.
  • iabBrowser.tabs.list() fails with: No active Codex browser pane available.
  • Playwright MCP is separate and only shows its own about:blank page; I am not using that as evidence for the in-app Browser.

Why this is still a product follow-up for us:

  • The backend is discoverable, but there is no active Codex browser pane to list or navigate from the automation side.
  • This prevents following the documented workflow where Codex opens or shares an in-app Browser view for user confirmation.
  • The Chrome Extension backend is working now, so this no longer appears to be a general browser runtime/bootstrap failure. It is specifically the in-app Browser pane/visibility/active-pane path.
NemuKei · 3 months ago

Follow-up correction from the same Windows environment.

After the previous comment, I continued testing the in-app Browser backend and found that the active pane path can recover in this thread:

  • agent.browsers.get("iab") succeeds.
  • Initial tabs.list() had failed with No active Codex browser pane available.
  • Calling tabs.new() succeeded and created tab id 1.
  • tabs.get("1") returned a rich tab object with goto(), title(), url(), screenshot(), and Playwright helpers.
  • Navigating that tab to a local test server succeeded:
  • request log saw GET /iab-styled-check
  • title was IAB Styled Check
  • DOM/body text included IAB Styled OK and white background and yellow box
  • computed styles showed white background and black text
  • viewport was 1280x720
  • screenshot returned JPEG bytes and rendered the expected page

So the current narrower issue is not active pane creation anymore. The remaining mismatch is that browser metadata advertises the visibility capability, but the high-level browser object returned by agent.browsers.get("iab") exposes only browserId, capabilities, tabs, and user; I do not see a callable visibility object on that returned object in this run.

Operationally, we can now use the in-app Browser for local/dev GUI checks via tabs.new() + goto() + screenshot/DOM checks. We will keep tracking the missing callable visibility surface separately.