Skip to content

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

Open
Open
Windows Codex App: in-app browser visibility.set(true) succeeds but visibility.get() remains false#23962
Labels
appIssues related to the Codex desktop appbrowserbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

Description

@NemuKei
NemuKei
opened on May 22, 2026

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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    browser
    on May 22, 2026

  2. github-actions commented on May 22, 2026

    @github-actions
    github-actionsbot
    on May 22, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. NemuKei commented on May 27, 2026

    @NemuKei
    NemuKei
    on May 27, 2026
    Author

    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.

  4. NemuKei commented on May 27, 2026

    @NemuKei
    NemuKei
    on May 27, 2026
    Author

    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.

  5. trukhinyuri commented on Aug 28, 2026

    @trukhinyuri
    trukhinyuri
    on Aug 28, 2026

    Still reproduces, and it is not Windows-specific: same behavior on macOS with a current desktop build.

    Environment

    • ChatGPT/Codex desktop app: 26.825.31414 (build 7287)
    • Browser plugin: browser@openai-bundled 26.825.31414
    • Backend: Codex in-app browser (iab), advertised browser capabilities include visibility and viewport
    • macOS: 26.6.2 (25G83), Darwin 25.6.0 arm64 arm

    Result

    With a selected in-app browser tab:

    1. await (await browser.capabilities.get("visibility")).set(true) returns normally, with no error.
    2. await (await browser.capabilities.get("visibility")).get() returns false immediately, and still false after a 750 ms delay.

    Navigation, DOM snapshots, screenshots, clicking, typing, scrolling, viewport changes, and clipboard round-trips in that same tab all work, so the problem looks isolated to the visibility state / presentation-confirmation path, exactly as described in the original report.

    The practical impact is the same on macOS: an agent can open and inspect a page but cannot honestly confirm that it was presented to the user, so a screenshot is currently the only usable evidence that the browser is visible.

  6. furuchanchan commented on Sep 23, 2026

    @furuchanchan
    furuchanchan
    on Sep 23, 2026

    Reproduced again on macOS with a newer build, plus two observations that may help narrow it down.

    Environment

    • Codex desktop app 26.915.31945 (build 9922), macOS 26.4.1 (25E253), arm64
    • Task 01a0cca2-4187-7d32-934c-5f08a990d2cf (included in case it helps correlate server-side logs)

    Observed

    1. Created a tab for https://example.com/ with visible: true → tab 1, providerTabId browser-use:7f6834fe-…. The page itself loads and is fully operable: AX snapshot returns "Example Domain", DOM reads work.
    2. visibility.get() → false. visibility.set(true) returns without error but get() is still false immediately after, and remains false after reconnecting to the same tab.
    3. open_in_codex with the verified providerTabId returns queued and never resolves to visible.
    4. Transient recovery, then regression: immediately after navigate_to_codex_page to the owning task, visibility.get() returned true once; on the very next selected-tab/AX check it was false again (selected tab still 1). So the state flaps rather than being permanently stuck.
    5. Possibly related: the app log shows this conversation's browser session route being duplicate-reassigned between two app windows (window 1 → window 4 → window 1) within ~3 s, followed by repeated No ChatGPT browser route is available for browser session warnings — coinciding with the stuck visibility=false / queued state. See also [macOS 26.908.70816] cua.getState() times out with repeated missing IAB session-route errors #46100 and Browser Use loses active pane binding after chat/browser detach #20743. Correlation only; causation not proven.

    Same symptom has reproduced across multiple tasks and days on builds 26.908.70816 (build 9275) and 26.915.31945. In one session visibility briefly recovered to true after user-side interaction, then regressed to false when a new tab was created. A controlled single-window test (closing duplicate windows + clean restart) is the next isolation step on my side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbrowserbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions