Windows Codex App: in-app browser visibility.set(true) succeeds but visibility.get() remains false
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 codexcommand:C:\Program Files\WindowsApps\OpenAI.Codex_26.519.2736.0_x64__2p2nqsd0c76g0\app\resources\codex.execodexversion 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
visibilityandviewport - 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:
- Bootstrap
browser-client.mjsand select theiabbrowser. - Get the
visibilitycapability:await browser.capabilities.get("visibility"). - Call
await visibility.get(). - Call
await visibility.set(true). - Poll
await visibility.get()at 0ms, 250ms, 1000ms, 2500ms, and 5000ms. - Open a local test page in a new in-app browser tab, e.g.
http://127.0.0.1:<port>/p7-08-updated-navigation. - Confirm page load by title, DOM snapshot, and local HTTP request log.
- 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()remainsfalseat 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(...)succeedswaitForLoadState({ 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.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗