Codex app: make the external-browser gesture deterministic across links and local HTML files

Open 💬 1 comment Opened Aug 2, 2026 by myrosla

What version of the Codex App are you using?

26.727.51351 (build 6119)

What platform is your computer?

macOS 26.2 (25C56), Apple Silicon

Default browser: Google Chrome for HTTP, HTTPS, and HTML files.

What issue are you seeing?

There is no documented, deterministic modifier-click action that means always open this target in the system external browser across Codex App surfaces.

Observed on a normal GitHub link in a Codex response, with the configured default target set to the external browser:

Command-click opened the link in the Codex in-app browser.
Shift-click opened the link in Google Chrome.

This is confusing because Command-click is not an "external browser" command. It means "use the alternate destination". Shift-click does not appear to be an explicit external-browser command; on this path, it falls through to the configured default destination.

The behavior also differs between:

normal HTTP/HTTPS links in assistant responses
links that explicitly force the external browser
generated local HTML file references or result cards
local URL/localhost previews
file-reference "Open with" and "View in browser" actions

The user must guess between a normal click, Command-click, Shift-click, or a context menu.

Why the external browser is required

My goal is not to alternate between destinations. I need one reliable action that always opens a link in my system browser.

My external browser contains the authenticated sessions, profiles, extensions, cookies, and saved data required for my work. The Codex in-app browser does not have this context.

When a link opens in the in-app browser, I must close it and try again with another modifier or context-menu action. This creates repeated friction.

One documented gesture, such as Shift-click, should always mean "Open in external browser" across web links, localhost URLs, local HTML files, and generated result cards.

What steps can reproduce the bug?

Set the normal web-link destination to the system external browser.
Open a Codex response that contains an HTTP/HTTPS link.
Command-click the link.
Observe that it opens in the Codex in-app browser.
Shift-click the same link.
Observe that it opens in the system external browser.
Repeat with a generated local .html file reference or result card.
Observe that the same user intent can require a different action or context menu.

What is the expected behavior?

Provide one documented and deterministic gesture for:

Always open in the system external browser

A good option is:

Shift-click: always open in the system external browser

Keep:

normal click controlled by the configured default destination
Command-click available for "alternate destination" or "open in new tab", if desired

The explicit external-browser gesture must have the same result for:

HTTP/HTTPS links
localhost links
local HTML files that can be opened by the default browser
generated HTML result cards
Markdown file references

A tooltip or context-menu label should show the shortcut.

Additional information

Inspection of the packaged macOS app matches the observed behavior:

The standard link handler maps the platform primary modifier to Command on macOS.
Command-click is converted to openTargetIntent: "alternate".
The destination resolver implements "alternate" by flipping the current preference between "in-app-browser" and "external-browser".
Shift is not used by this standard destination-selection path. Therefore, Shift-click follows the default destination in this example.
Some components bypass the preference logic with useExternalBrowser: true.
Local URLs use a separate open-local-url-in-target-preference.
Local HTML file references use a separate file-opening path with "View in browser", "Open with", and preferred application targets.

Related but not duplicate:

#30773 requests opening external links without switching focus.
#32078 reports broken link-opening actions on Windows.

This issue is about one consistent, discoverable external-browser gesture across Codex App surfaces.

View original on GitHub ↗

1 Comment

thnk2wn · 20 days ago

Additional reproduction on a newer macOS build:

Codex desktop app: 26.803.41515 (build 6321)
macOS: 26.6 (25G70)
Browser setting: Web URL and link open destination → Default browser
Local URL open destination: ChatGPT

An assistant response contained two adjacent, ordinarily rendered Markdown HTTPS links to GitHub pull requests on the same organization. Clicking the first link opened it in the Codex in-app browser. Clicking the second link, and subsequent link clicks, opened them in the system default browser, despite the links having the same Markdown shape and destination domain and no intentional change in click gesture.

Important precondition: immediately before those user clicks, the assistant had used Codex Browser Use to open both target pull-request URLs in agent-controlled in-app browser tabs while verifying reviewer state. Those in-app tabs therefore already existed. The first user click may have surfaced or reused one of those existing agent-created tabs instead of honoring the configured external destination; subsequent clicks then routed to the default browser. That causal link is not proven, but the existing Browser Use state may be necessary to reproduce the behavior.

Because the configured destination for web URLs is Default browser, the first ordinary HTTPS link opening in the in-app browser appears to violate the selected preference. The later links opening externally match the setting.

This appears to be the same class of routing inconsistency described here, but it also suggests that the destination can change between ordinary clicks—not only between Command-click and Shift-click. A deterministic normal-click destination that always honors the configured web URL preference would cover this case.