What version of the Codex App are you using (From “About Codex” dialog)?
Windows Codex Desktop, exact app build not shown in this run. CLI visible from the same environment:
Relevant features from codex features list:
browser_use stable true
in_app_browser stable true
Browser Use plugin observed locally:
browser-use/0.1.0-alpha1
backend = "iab"
What platform is your computer?
Windows desktop app.
What issue are you seeing?
Browser Use screenshot proof has two bad failure modes on Windows:
- When the screenshot path is forced away from target-surface capture, the image can capture the human-visible Codex/chat window instead of the controlled Browser Use tab.
- When the screenshot path is kept on the target browser-tab surface,
Page.captureScreenshot can time out, even though the Browser Use tab and DOM snapshot are functional.
The first mode is actively misleading because the screenshot can show whatever the user is currently looking at, often a different chat, instead of the Browser Use session the agent is controlling.
The second mode leaves no reliable visual proof path for the controlled in-app browser tab on the affected Windows setup.
Local evidence
In a local Browser Use repair pass, the screenshot paths in browser-client.mjs were traced to CDP Page.captureScreenshot calls. A local patch had forced fromSurface: false, which avoided some capture problems but caused screenshots to come from the visible app/window surface rather than the target browser tab.
After restoring the target-tab invariant, Browser Use could still initialize and operate:
browser-use plugin loaded from C:\Users\brade\.codex\plugins\cache\openai-bundled\browser-use\0.1.0-alpha1\scripts\browser-client.mjsbackend = "iab"- a local
file:// test page loaded successfully
tab.playwright.domSnapshot() saw the expected marker text from the target page
But target-surface screenshot capture could time out for the same tab.
Expected behavior
Screenshot APIs for Browser Use should capture the controlled browser tab surface, not the currently visible Codex/chat window.
Affected APIs include:
tab.cua.get_visible_screenshot()
tab.playwright.screenshot({ fullPage: false })
tab.playwright.screenshot({ fullPage: true })
tab.playwright.screenshot({ clip })If the target-tab screenshot path cannot capture the image, it should fail explicitly with a clear Browser Use screenshot error. It should not silently fall back to a desktop/current-window capture that can show an unrelated chat or window.
Steps to reproduce
- Open Codex Desktop on Windows with the in-app browser enabled.
- Start a Browser Use session with the
iab backend.
- Navigate the Browser Use tab to a simple local page or
file:// page with an obvious marker.
- Confirm
tab.playwright.domSnapshot() can see the marker.
- Request a visible screenshot or full-page screenshot through Browser Use.
- Observe either:
- target-surface capture times out, or
- if a fallback uses
fromSurface: false, the screenshot can show the human-visible Codex/chat window instead of the target Browser Use tab.
Why this appears distinct from existing issues
#19429 reported incorrect screenshot region/size caused by CSS-pixel vs DIP coordinate handling and is closed. This report is about a different invariant: screenshots must come from the controlled browser tab, but the correct target-surface capture path can time out on Windows, while the workaround/fallback can capture the wrong window entirely.
Related but not exact duplicates:
Additional information
A local instruction workaround now tells agents to use DOM snapshots or report the screenshot blocker rather than showing a desktop/current-window screenshot as browser proof. That helps avoid misleading evidence, but it does not fix the underlying Windows target-tab screenshot capture path.
What version of the Codex App are you using (From “About Codex” dialog)?
Windows Codex Desktop, exact app build not shown in this run. CLI visible from the same environment:
Relevant features from
codex features list:Browser Use plugin observed locally:
What platform is your computer?
Windows desktop app.
What issue are you seeing?
Browser Use screenshot proof has two bad failure modes on Windows:
Page.captureScreenshotcan time out, even though the Browser Use tab and DOM snapshot are functional.The first mode is actively misleading because the screenshot can show whatever the user is currently looking at, often a different chat, instead of the Browser Use session the agent is controlling.
The second mode leaves no reliable visual proof path for the controlled in-app browser tab on the affected Windows setup.
Local evidence
In a local Browser Use repair pass, the screenshot paths in
browser-client.mjswere traced to CDPPage.captureScreenshotcalls. A local patch had forcedfromSurface: false, which avoided some capture problems but caused screenshots to come from the visible app/window surface rather than the target browser tab.After restoring the target-tab invariant, Browser Use could still initialize and operate:
browser-useplugin loaded fromC:\Users\brade\.codex\plugins\cache\openai-bundled\browser-use\0.1.0-alpha1\scripts\browser-client.mjsbackend = "iab"file://test page loaded successfullytab.playwright.domSnapshot()saw the expected marker text from the target pageBut target-surface screenshot capture could time out for the same tab.
Expected behavior
Screenshot APIs for Browser Use should capture the controlled browser tab surface, not the currently visible Codex/chat window.
Affected APIs include:
If the target-tab screenshot path cannot capture the image, it should fail explicitly with a clear Browser Use screenshot error. It should not silently fall back to a desktop/current-window capture that can show an unrelated chat or window.
Steps to reproduce
iabbackend.file://page with an obvious marker.tab.playwright.domSnapshot()can see the marker.fromSurface: false, the screenshot can show the human-visible Codex/chat window instead of the target Browser Use tab.Why this appears distinct from existing issues
#19429 reported incorrect screenshot region/size caused by CSS-pixel vs DIP coordinate handling and is closed. This report is about a different invariant: screenshots must come from the controlled browser tab, but the correct target-surface capture path can time out on Windows, while the workaround/fallback can capture the wrong window entirely.
Related but not exact duplicates:
Additional information
A local instruction workaround now tells agents to use DOM snapshots or report the screenshot blocker rather than showing a desktop/current-window screenshot as browser proof. That helps avoid misleading evidence, but it does not fix the underlying Windows target-tab screenshot capture path.