Built-in browser responsive viewport resets after agent releases tab

Resolved 💬 2 comments Opened Jul 21, 2026 by kavishagarwal Closed Jul 21, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Bug: Built-in browser Responsive viewport resets when agent releases the tab

Codex feedback upload completed. Uploaded diagnostic thread: 019f8597-985b-76b2-bd6f-01ee63d65cf8.

Summary

The Codex/ChatGPT desktop app's native built-in browser can be placed into its Responsive viewport mode at 1440 x 900, but that viewport is not preserved when the agent finishes the turn or releases/finalizes the browser tab. The browser immediately falls back to the narrow physical side-pane width, causing the website to render at a tablet/mobile breakpoint. This makes the native annotation workflow unreliable for MacBook-size website review.

Environment

  • App bundle: com.openai.codex
  • App version: 26.715.61943 (build 5628)
  • macOS: 26.5.2 (build 25F84)
  • Architecture: Apple Silicon / arm64
  • Reproduction thread ID: 019f8576-e159-77b2-b5d6-317892195df9
  • Website: Next.js dev server at http://localhost:3000/
  • Desired viewport: 1440 x 900
  • Built-in browser annotations are required

Reproduction steps

  1. Open http://localhost:3000/ in the native Codex built-in browser.
  2. Enable the native Responsive viewport toolbar (the row showing Dimensions: Responsive).
  3. Set width to 1440 and height to 900.
  4. Confirm the page renders at the desktop breakpoint: full desktop navigation and horizontally aligned CTA buttons are visible.
  5. Let the agent finish its turn and release/finalize the tab. This was reproduced with both browser finalization modes tested: deliverable and handoff.
  6. Inspect the same browser tab after control is released.

Actual result

  • Before release, JavaScript measurement reports window.innerWidth = 1440 and window.innerHeight = 900; the desktop breakpoint is active.
  • After release/finalization, the Responsive toolbar disappears and the same tab measures approximately 621 x 863, matching the narrow physical browser pane.
  • The website switches to its tablet/mobile layout (hamburger navigation and vertically stacked buttons).
  • Reopening/focusing the browser can preserve this incorrect narrow state.
  • The override remains correct only while the agent keeps the browser-control session attached and the turn active.
  • Using a custom page wrapper or non-native preview is not a viable workaround because it removes or compromises native element annotation.

Expected result

The native Responsive viewport selection (1440 x 900) should be user-visible browser state and should persist:

  • after the agent releases the tab;
  • after the agent's turn completes;
  • when the browser tab is refocused or reopened;
  • while retaining the native element annotation feature.

At minimum, releasing agent control should not silently clear a viewport selected through the native Responsive toolbar.

Root-cause evidence / likely component boundary

This appears to be a lifecycle/persistence bug between browser automation control and the user-owned built-in browser tab:

  1. The viewport capability successfully applies 1440 x 900 while the agent owns the tab.
  2. The same tab immediately returns to its physical pane dimensions after finalization/release.
  3. Both deliverable and handoff finalization paths produce the reset.
  4. No documented persistent viewport setting was found, and the agent is intentionally blocked from manipulating the Codex app's own window chrome.

Inference: the responsive/device-metrics override is scoped to the temporary automation/CDP session and is cleared when that session detaches, rather than being persisted in the browser tab's user-facing Responsive toolbar state.

User impact

This blocks the intended workflow of:

  1. Ask Codex to open a local website at a MacBook viewport.
  2. Review the true desktop layout in the built-in browser.
  3. Annotate page elements natively.
  4. Continue the coding task from those annotations.

The current workaround is to keep the agent turn and browser-control session alive indefinitely while the user reviews, or require the user to manually re-enable and re-enter the Responsive dimensions every time.

Suggested fix

  • Persist the Responsive toolbar enabled state and its width/height as tab-level browser state independent of the automation session.
  • On automation detach/finalize, transfer the current emulation dimensions to the user-owned Responsive toolbar instead of clearing them.
  • Add a regression test covering set viewport -> finalize(deliverable/handoff) -> same tab retains 1440 x 900.
  • Ensure native element annotation remains available throughout.

Screenshots available

  1. Narrow fallback after release, showing hamburger navigation and stacked CTAs.
  2. Correct native Responsive toolbar at 1440 x 900, showing desktop layout.
  3. Repeat of the narrow fallback after the agent reported that it had preserved the viewport.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

  • #34335

Powered by Codex Action

kavishagarwal · 1 month ago

Closing as a duplicate of #34335. I added the macOS reproduction, measured 1440 × 900621 × 863 reset, both finalization paths, annotation impact, app/OS details, and diagnostic upload reference to the canonical issue.