[Windows] In-app browser device preview toolbar closes when Browser Use returns control
Codex App version
Microsoft Store package version 26.715.3651.0 on Windows x64.
What issue are you seeing?
When Browser Use sets the in-app browser to an iPhone-sized responsive/device preview (393 × 852), the preview works while the agent controls the browser, but the visible device-preview toolbar closes again as soon as the Browser Use step ends and control returns to the user.
This also reproduced when the agent deliberately did not call tabs.finalize(). During the active Browser Use call, page evaluation confirmed:
window.innerWidth === 393window.innerHeight === 852
After the tool call returned, the user observed the device-preview toolbar close again.
Steps to reproduce
- Open a local web page in the Codex in-app browser.
- Start Browser Use and set the browser viewport:
``js``
await viewport.set({ width: 393, height: 852 })
- With the tab claimed, reload if necessary and verify the page viewport is 393 × 852.
- End the Browser Use tool call and return control to the user.
- Observe that the visible responsive/device-preview toolbar closes or is no longer visibly pinned.
- Repeat without calling
browser.tabs.finalize(...); the same behavior occurs.
Expected behavior
The user-selected or agent-set device preview should remain visibly active until the user or agent explicitly resets it.
Actual behavior
The device preview is temporary to the Browser Use control step. Its toolbar is dismissed when control returns, so the agent cannot leave the requested iPhone preview visibly pinned for the user.
Additional context
The first reproduction used tabs.finalize(), which also closed the toolbar. A second reproduction intentionally omitted finalization, but the toolbar still closed after the Browser Use call ended.
I searched existing issues before filing. Issues such as #28062 cover different device-toolbar problems (for example, blank zoom options), not this toolbar-lifecycle/persistence behavior.
2 Comments
Confirming the same lifecycle/persistence bug on macOS, so this is not Windows-specific.
Environment
26.715.61943(build5628)26.5.2(build25F84)arm64Measured reproduction
1440 × 900.window.innerWidth === 1440andwindow.innerHeight === 900; the desktop breakpoint is active.621 × 863, matching the physical side-pane size.This reproduced through both
deliverableandhandofffinalization paths. The override remains correct only while the Browser Use control session stays attached. Native annotations are required in this workflow, so replacing the browser with a custom wrapper is not a viable workaround.Diagnostic feedback upload:
019f8597-985b-76b2-bd6f-01ee63d65cf8.The fuller macOS report is #34576; I am closing that issue as a duplicate so the cross-platform evidence stays consolidated here.
Adding a related user-facing requirement from the Codex desktop in-app Browser:
Requested persistent default
Ideally, the in-app Browser should offer a “Remember/Persist as my default” option, or an equivalent setting under Browser settings, so the selected responsive preset, viewport dimensions, and zoom are restored for new browser tasks and remain available after Browser Use returns control.
This should be a default, not a hard lock: the user or model should be able to override it for a specific device, breakpoint, orientation, or display-scale test, with the active override visible and easy to reset.
This would make visual QA consistent and avoid reconfiguring the same browser state at the start of each task. It complements the toolbar-lifecycle problem already described in this issue.