External links open without user providing consent

The video for demonstrating the issue: https://github.com/user-attachments/assets/a10edf92-bf6a-4ac9-9a1a-f2ab0e373410

This is by design currently, so I don't think we'd consider this a bug.

I'm going to change this to a feature request, and we'll see if other users want a user consent dialog in this path. Personally, I prefer not having an extra speed bump here, but I can understand that other users might want one.

For me, the "Do you want to open the link" dialog is being shown, but the link still opens without any dialogue-interaction.

1. Codex prints link
2. Click link

3+4: Open External-Website Dialogue + Open Website at the same time

I think that this should therefore now be treated as a bug again, and not a design decision.

<img width="2201" height="820" alt="Image" src="https://github.com/user-attachments/assets/7d4f8f90-436e-4c75-9052-6fddee0d6a06" />

I understand that opening external links without an extra consent step may currently be considered a product decision.

However, I don’t think this should be tracked only as an enhancement, because in my case there is also a clear bug.

What I am seeing is not just “no consent dialog”. In my case, a single click triggers multiple link-opening paths at the same time:

1. The browser opens immediately.
2. VS Code still shows its external-link security warning.
3. If I click Open in that warning dialog, the browser opens again.

So this is not only a request for a user-consent dialog. It is also a duplicate-navigation bug: in my case, one click results in two separate external-open flows being active at once.

I investigated this using Codex by checking the installed VS Code extension bundle and the recent Codex extension logs locally. What I found is:

• The webview link handler sends open-in-browser, and the extension host calls vscode.env.openExternal(...).
• At the same time, VS Code’s own external-link protection path is still active, which is why the warning dialog appears.
• In the extension logs I also see repeated unsupported link-routing requests such as vscode://codex/open-in-targets and vscode://codex/local-environments, which further suggests that link handling is not being routed through a single consistent path.

For example, recent log entries include:

• Error fetching errorMessage="local-environments is not supported in the extension" ... url=vscode://codex/local-environments
• Error fetching errorMessage="open-in-target not supported in extension" ... url=vscode://codex/open-in-targets

Even if the “open immediately without extra consent” part is by design, the “same click opens the browser once immediately, then opens it again after the VS Code warning dialog” part looks like a bug in my case and should be tracked as such.

!Image
(github is already trusted domain so it opened twice without prompt)

I have patched it with codex itself. It works.

--- a/src/components/markdown.tsx
+++ b/src/components/markdown.tsx
@@
       return (
         <a
           href={href}
           className="decoration-opacity-50 text-token-text-link-foreground underline decoration-current decoration-[0.5px]"
           target="_blank"
           rel="noopener noreferrer"
-          onClick={(event) => {
-            if (!href || !isExternalUrl(href)) {
-              return;
-            }
-            event.preventDefault();
-            messageBus.dispatchMessage("open-in-browser", {
-              url: normalizeExternalUrl(href),
-            });
-          }}
         >
           {children}
         </a>
       );
     },

A more precise update after additional investigation with Codex:

I decoded the original source from the sourcemap and tested a local patch against the installed VS Code extension bundle.

In the original markdown renderer, external links were both:

• rendered as normal anchors with href / target="_blank" / rel="noopener noreferrer"
• wired to dispatch open-in-browser on click

When I removed only the custom open-in-browser click handler, both the duplicate browser launch and the VS Code warning dialog disappeared in my local test. That strongly suggests the extra open-in-browser handler was at least part of the problem.

So the duplicate-open issue still looks like a real bug, separate from the product decision about whether external links should require explicit user consent.

@etraut-openai Trust Domain is necessary for safety reasons: What if Codex reports misleading urls like opanai.com for openai.com? The latter is in trusted domains and users will notice if they click the former one.

This is by design currently, so I don't think we'd consider this a bug. I'm going to change this to a feature request, and we'll see if other users want a user consent dialog in this path. Personally, I prefer not having an extra speed bump here, but I can understand that other users might want one.

@etraut-openai

Respectfully, I believe there is a misunderstanding of the technical issue here. This isn't a request for a "consent dialog", it is a report of a duplicate navigation bug caused by redundant event handling.

In no scenario is opening the same URL twice the intended UX. Other major extensions handle this properly.

Labeling this as a "Feature Request for a consent dialog" misses the point. The fix is simply to de-duplicate the call stack so that only one entity is responsible for launching the external URI. Can we please re-open this as a bug?

@akaSurreal, ah you're right. I missed that subtlety in the OP's description. Changing back to a bug report.