Issue Station
Sign In
Tools hereToolbox

codex - 💡(How to fix) Fix Feature request: allow Browser use to use an external/system browser profile [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#21145•Fetched 2026-05-06 06:25:58
View on GitHub
Comments
1
Participants
2
Timeline
4
Reactions
0
Author
GGBondBlueWhaleGGBondBlueWhale
Participants
GGBondBlueWhaleGGBondBlueWhalegithub-actions[bot]github-actions[bot]
Timeline (top)
labeled ×3commented ×1

Root Cause

The main reason is that many real workflows involve pages where the user is already signed in through their normal browser. The external browser often already has the required cookies, sessions, SSO state, password-manager flow, 2FA trust state, and existing login records. With the current built-in browser, users often need to sign in again, and some authentication flows may not work as smoothly as they do in a regular browser.

RAW_BUFFERClick to expand / collapse

What variant of Codex are you using?

macOS App

What feature would you like to see?

I would like Codex Browser use to support an option to open and use a user-selected external/system browser, such as Chrome, Safari, or Edge, instead of being limited to the built-in in-app browser.

The main reason is that many real workflows involve pages where the user is already signed in through their normal browser. The external browser often already has the required cookies, sessions, SSO state, password-manager flow, 2FA trust state, and existing login records. With the current built-in browser, users often need to sign in again, and some authentication flows may not work as smoothly as they do in a regular browser.

Why this would help

  • Local development apps, admin dashboards, internal tools, cloud consoles, and SaaS products often require login before the useful page can be tested.
  • Users may already be authenticated in Chrome/Safari/Edge, so reusing that session would save time and reduce friction.
  • It would make Browser use more practical for real-world debugging and product testing, especially when pages depend on cookies or account-specific state.
  • It would avoid repeatedly logging in inside the in-app browser just to let Codex inspect or interact with a page.

Suggested behavior

  • Add a “Use external browser” or “Open in system browser” mode for Browser use.
  • Allow the user to select a browser/profile, for example Chrome, Safari, Edge, or the system default browser.
  • Let Codex interact with a specific launched tab/window in that browser context, after explicit user permission.
  • Keep the built-in browser as the default/sandboxed option for users who prefer isolation.
  • Make this opt-in per thread, per site, or per session, with a visible indicator that Codex can view/control that browser tab.
  • Provide a clear way to stop/revoke control at any time.

Security/privacy expectations

This should not silently read all browser data or cookies. The safer version would be an explicit, user-approved external-browser handoff where Codex can only see/control the specific tab or window that the user has opened for Browser use.

extent analysis

TL;DR

To address the limitation, consider implementing an "Open in system browser" mode that allows users to select an external browser and grants Codex permission to interact with a specific tab or window.

Guidance

  • Investigate existing browser extension APIs or protocols (e.g., Chrome's native messaging API) that could enable secure communication between Codex and an external browser.
  • Design a user interface for selecting and configuring the external browser option, including a clear indicator of when Codex is controlling a browser tab.
  • Develop a permission system that requires explicit user approval before Codex can interact with an external browser tab, ensuring user privacy and security.
  • Consider implementing a "handoff" mechanism that allows Codex to launch a new tab in the selected external browser and then interact with it, while respecting browser security and privacy boundaries.

Example

No code example is provided due to the high-level nature of the request and the need for further technical investigation.

Notes

The implementation details will depend on the specific browser APIs and protocols available, as well as the security and privacy requirements of the Codex application.

Recommendation

Apply a workaround by implementing the suggested "Open in system browser" mode, as it addresses the user's need for a more seamless authentication experience while respecting security and privacy concerns.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#model loading#dependency error#configuration error#environment variable#network issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING