Codex app version
26.818.5229.0 (Windows x64; embedded Chromium/File version 151.0.7922.170)
Model
GPT-5.6 Sol
What happened
The Codex in-app browser pane was visibly open to a blank New Tab page, while the browser-control runtime reported a different background tab successfully navigated to GitHub. The agent therefore believed the GitHub login page was open, but the user could not see it.
This happened repeatedly during a GitHub App authorization handoff and caused multiple false claims that a login/authorization page had been opened.
Reproduction
- Open the in-app browser pane in Codex Desktop on Windows.
- From an agent task, create a browser tab with
iab.tabs.new().
- Navigate it to
https://github.com/settings/installations.
- Observe that DOM inspection reports
Sign in to GitHub and the controlled tab list contains the GitHub login URL.
- Observe the visible in-app browser pane: it can remain on the blank New Tab / Start browsing screen.
iab.user.openTabs() returned an empty list even though the blank tab was visibly present.- Calling the browser
visibility capability with set(true) was followed by get() returning false.
- Calling
markDeliverable() while attempting to surface the tab hung until the 30-second tool timeout and reset the browser-control session.
Expected behavior
- The tab returned by
iab.tabs.new() and navigated with goto() should be the tab shown in the visible in-app browser pane when the workflow requires a login handoff.
openTabs() should reflect the visible blank tab, or the API should clearly distinguish hidden agent tabs from user-visible tabs.visibility.set(true) should either make the browser visible and return true, or return a clear actionable error.markDeliverable() should not hang until the control session is reset.
Actual behavior
- DOM/control state and the user-visible browser pane diverged.
- The runtime exposed a valid GitHub login DOM in a background tab while the user saw only a blank new tab.
- Visibility state stayed false.
- Delivering the tab timed out.
Impact
Authentication handoff became impossible and the agent gave incorrect user-facing status. Repeated retries made the workflow significantly worse.
Additional evidence
A screenshot showing the Codex task beside the visibly blank in-app browser pane is available. The affected session identifier can be provided privately to OpenAI support if needed.
Codex app version
26.818.5229.0 (Windows x64; embedded Chromium/File version 151.0.7922.170)
Model
GPT-5.6 Sol
What happened
The Codex in-app browser pane was visibly open to a blank New Tab page, while the browser-control runtime reported a different background tab successfully navigated to GitHub. The agent therefore believed the GitHub login page was open, but the user could not see it.
This happened repeatedly during a GitHub App authorization handoff and caused multiple false claims that a login/authorization page had been opened.
Reproduction
iab.tabs.new().https://github.com/settings/installations.Sign in to GitHuband the controlled tab list contains the GitHub login URL.iab.user.openTabs()returned an empty list even though the blank tab was visibly present.visibilitycapability withset(true)was followed byget()returningfalse.markDeliverable()while attempting to surface the tab hung until the 30-second tool timeout and reset the browser-control session.Expected behavior
iab.tabs.new()and navigated withgoto()should be the tab shown in the visible in-app browser pane when the workflow requires a login handoff.openTabs()should reflect the visible blank tab, or the API should clearly distinguish hidden agent tabs from user-visible tabs.visibility.set(true)should either make the browser visible and returntrue, or return a clear actionable error.markDeliverable()should not hang until the control session is reset.Actual behavior
Impact
Authentication handoff became impossible and the agent gave incorrect user-facing status. Repeated retries made the workflow significantly worse.
Additional evidence
A screenshot showing the Codex task beside the visibly blank in-app browser pane is available. The affected session identifier can be provided privately to OpenAI support if needed.