Hyperlinks not rendered properly and non-clickable now in VS Code extension

Thanks for flagging. I noticed this too - the model sometimes wraps markdown links in codeblocks so the app/ vs code wouldn't link it. I made a fix for this yesterday. Should be deployed ~ soon ~

As an intermediate workaround, I created ~/.codex/AGENTS.md with the following content:

``` markdown

Global Agent Instructions

VS Code Clickable File Links

• Always output file references as Markdown links with an absolute filesystem path and optional line number using this format:
• [label](/<absolute-path>:line)
• On Windows, use forward slashes and include the drive letter in the path, for example:
• [file.h](/c:/project/src/file.h:100)
• Prefer this format for every file reference so links open directly in this VS Code chat environment.
• Do not use vscode:// links for file references.

That solved it for me.

<img width="562" height="23" alt="Image" src="https://github.com/user-attachments/assets/decaac50-eef7-468e-9f72-9e8abc6c4e64" />

Updated to the newest version 26.304.20706, still has some issues with links, though maybe the proper markdown links wrapped in codeblocks is now working, it's just the (GPT-5.3-Codex) model often doesn't even use markdown links. But in any case, here is another example where it used to work (at least the first one is clickable, the second one is not) like so:

<img width="351" height="22" alt="Image" src="https://github.com/user-attachments/assets/dcb9d19c-b926-4ba4-9d29-40f9fae957d5" />

I don't have any specific instructions in my AGENTS.md (or anywhere else) to force any format on links, I simply have "refer to both the symbol's name and the location in the source file", I trust that the model knows what to do, and that the UI knows how to handle the model's output.
@pash-openai I wonder what your or the general codex team's best practice suggestion is. Because to me as a user if something used to work but now it doesn't, that's a regression bug. Although I may be able to harden it by explicitly telling it to follow markdown format for links, but shouldn't that be part of the system prompt...? Also, on the point that the (line 1867) renders as a link but doesn't actually work when I click, again as a user, it's a bit frustrating when what I see is not what I get.

Sorry for the nitpick, it's not a huge deal but when I look at past codex sessions' chat history it's quite inconvenient.

I can reproduce a closely related variant of this on macOS as well.

Environment:

• Codex VS Code extension: 26.313.41514
• VS Code: 1.111.0
• OS: macOS 26.3.1

Behavior in my case:

• File references in Codex responses are rendered as blue links in the VS Code chat panel.
• Clicking them does not navigate to the file in the editor.
• This affects both:
• workspace files
• non-workspace files such as VS Code user settings
• In my setup, the click does not successfully open anything in the editor.

So this seems broader than just one path format or one platform. It looks like the same renderer / link-handling pipeline is still broken on current macOS builds too.

Related duplicate report that was auto-closed in favor of existing issues:

• #14946

Additional finding after more testing on macOS:

The issue appears to be strongly related to spaces in the path.

What I verified:

• This works in the Codex VS Code chat panel:
• [AGENTS.md](/Users/thom/.codex/AGENTS.md:1)
• This does not work:
• [README.md](/Users/thom/Desktop/Localsend X/README.md:1)
• A no-space symlink to the same target does work:
• /Users/thom/.codex-links/localsend-readme.md -> /Users/thom/Desktop/Localsend X/README.md
• The same pattern also works for a file outside the workspace:
• /Users/thom/.codex-links/vscode-settings.json -> /Users/thom/Library/Application Support/Code/User/settings.json

So the current behavior seems to be:

• absolute-path + :line is the right link format
• but links fail when the path itself contains spaces
• a no-space symlink path works even when the real target path contains spaces

This may help narrow the bug down to path parsing / URI handling for spaces inside the VS Code extension webview link pipeline.

Current user workaround:

• create no-space symlinks for frequently referenced files/folders
• have Codex emit links using /absolute/path:line against those symlink paths

Still a problem as of the latest version.

Im haviing the same problema with the extesion on cursor

This malignant bug has existed for months, and openai just didn't do anything.

the link is openning chrome with this url:
https://file+.vscode-resource.vscode-cdn.net/c%3A/Users/username/.vscode/extensions/openai.chatgpt-26.5406.31014-win32-x64/webview/

Can we fix this?

was working, now broken again in 26.409.20454
VS Code Version: 1.115.0 (Universal)
macOS

If anyone is interested, here is the last pre-release version that has links working: 26.5406.40811

To install it select it from "Uninstall" drop down:
<img width="666" height="289" alt="Image" src="https://github.com/user-attachments/assets/8485134a-cb3c-4a28-a57e-d074196ad4c3" />

If anyone is interested, here is the last pre-release version that has links working: 26.5406.40811 To install it select it from "Uninstall" drop down: <img alt="Image" width="666" height="289" src="https://private-user-images.githubusercontent.com/59230/577036235-8485134a-cb3c-4a28-a57e-d074196ad4c3.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzYwNzA4NjEsIm5iZiI6MTc3NjA3MDU2MSwicGF0aCI6Ii81OTIzMC81NzcwMzYyMzUtODQ4NTEzNGEtY2IzYy00YTI4LWE1N2UtZDA3NDE5NmFkNGMzLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA0MTMlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwNDEzVDA4NTYwMVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTIxNTdjNjM4NTg3Y2Y1NDdlMTEyZmY1MTEwNGQ1MGU4Y2VlMjEzMGMxN2EyNjM3ZjI3NDE2ODYxZGM0MmUwMjImWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.iQrpEYHAF437ty2Ti5eRQZq5UavjEsgV0U7tkJlFgpc">

It really works! Thanks a lot! 🤝

I have the same problem from Windows WSL:

Visual Studio Code
Version: 1.115.0
OS: Windows_NT x64

Codex openai.chatgpt
Version 26.409.20454

There may be a related but separate bug upstream of the renderer/link-handler layer.

In my Codex session inside VS Code, the agent explicitly said it was being prevented by higher-priority injected session instructions from emitting vscode:// file links, and that URI schemes like vscode:// and file:// were forbidden for file references.

That suggests two distinct layers may be involved here:

1. The extension/UI problem described in this issue, where file references render incorrectly or are non-clickable.
2. A Codex instruction-layer problem, where the model is being told not to generate VS Code-openable links in the first place.

I filed the second issue separately here:

• #18191

If maintainers think that restriction is actually part of the same root cause, feel free to fold it in, but based on the behaviour it looks like a separate bug from the renderer/click-handling problem tracked in this issue.

To add on to this - though I know this is a VS Code ticket - the same behavior is exhibited in the IDEA integration.
path:line works from codex running in the IntelliJ terminal, but not from Codex plugin chat; markdown absolute links treat :line as part of filename; #L1, idea://open, and jetbrains://idea/navigate/reference all fail or escape to Chrome. Nothing I've been able to configure changed any of this behavior. The plugin integration with IDEA just doesn't work for file links at all.

I didn't find a specific IDEA ticket to attach this to, but will open a new one if advised to do so.

IDE: Intelli-J IDEA 2026.1 (Build #IU-261.23567.138, built on April 22, 2026)
OS: Mac OS X Tahoe (26.3.1 (25D2128)) on Apple M3 silicon
JetBrains AI Assistant plugin: 261.23567.193
Embedded Codex CLI binary: codex-cli 0.128.0
Codex CLI (from brew): codex-cli 0.130.0