›_ Codex Issues
Codex Issues / #16520

Fix unstable local file link navigation in the VS Code Codex chat window

Open 💬 10 comments Opened Apr 2, 2026 by Michelin-3-star-tires
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Fix unstable local file link navigation in the VS Code Codex chat window

Summary

In the OpenAI/Codex chat webview inside VS Code, local file links behave inconsistently on Windows. Some links are rendered as blue hyperlinks, but clicking them opens the browser instead of VS Code. Some links appear clickable but do nothing. The result also varies by file type and path encoding.

This issue is reproducible in local Windows workspaces.

Reproduction

  1. Emit a local file link in the chat window.
  2. Click the link.
  3. Observe whether VS Code opens the target file or whether the browser opens instead.

Observed behavior

  • A local resource URL can be treated as a normal external URL and open in the browser.
  • The special citation-style link format is unstable in this rendering path and often degrades to plain text.
  • Plain Markdown local links are currently the most reliable form.

Expected behavior

Any valid local file link should open the target file inside VS Code, not in a browser, and should work consistently across:

  • text files
  • images
  • archives
  • cache and metadata files
  • paths containing Chinese characters
  • paths containing special characters such as + and -

Why I believe this is an extension-side issue

This looks like a chain problem across three layers:

  1. Webview Markdown rendering
  • Some links are downgraded to plain external links, which sends clicks to browser behavior.
  1. Path encoding and decoding
  • Chinese characters, spaces, and special symbols can be percent-encoded in the URL layer.
  • If the path is not decoded before reaching the host, the string no longer matches the real filesystem path.
  1. Host-side open logic
  • A text-first opening strategy such as openTextDocument + showTextDocument is fine for source files, but it is unstable for images, archives, and binary files.

Because the relevant logic lives in the extension's webview and host integration, this appears to be a plugin integration issue rather than a VS Code core regression.

Verified fix direction

  • Detect local resource URLs in the click handler instead of treating every URL as an external link.
  • Decode and normalize the path in the open-file entry point before opening it.
  • Route text files to the editor and non-text files to vscode.open.
  • Keep a fallback path and log failures instead of silently doing nothing.

Verification results

After applying the above logic locally, I verified that the following link types can be opened reliably:

  • text files
  • Chinese directories and Chinese file names
  • images
  • archives
  • binary or compressed files
  • cache and metadata files
  • dist-info metadata files
  • filenames with + or -

Recommendation

Please upstream this fix in the extension source code instead of relying on a patched local bundle, because extension updates can overwrite local modifications. The most important safeguards are:

  1. Decode and normalize local paths consistently.
  2. Split text and non-text files into separate open flows.
  3. Add regression tests for the edge cases above.

Supporting notes are maintained in separate local English drafts and are intentionally omitted from this public-facing issue text.

View original on GitHub ↗

10 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #15377
  • #15859
  • #16245
  • #14946
  • #15711

Powered by Codex Action

Michelin-3-star-tires · 3 months ago

Adding the most important verification details from local Windows testing:

Confirmed stable cases after the fix

  • Plain Markdown local links work reliably for: .md, .json, .py, .csv, .log, .toml
  • Chinese directory names and Chinese file names work
  • Images work (.png)
  • Archives and compressed files work (.zip, .pkl.xz)
  • Cache / metadata / dist-info files work
  • Boundary filenames with + and - work (for example GMT-style metadata names)

What this confirms

  • A blue Markdown link is not enough by itself; the click must still go through the VS Code file-opening path.
  • The underlying problem was a combination of webview link handling, path decoding, and file-type routing.

Recommended upstream safeguards

  1. Decode and normalize local paths consistently in the open-file entry point.
  2. Split text and non-text files into separate open flows.
  3. Keep a vscode.open fallback for non-text files and failure cases.
  4. Add regression tests for Chinese paths, special characters, images, archives, cache files, and metadata files.

I also documented the full troubleshooting notes locally, but the short version above is the most useful signal for the upstream fix.

Michelin-3-star-tires · 3 months ago

Short follow-up after more Windows testing:

The critical upstream safeguard is explicit text vs non-text routing.

  • Text files (.md, .json, .py, .csv, .log, .toml) can stay on the editor path.
  • Images, archives, compressed files, cache/metadata files, and dist-info files should go through vscode.open (with fallback).

This avoids forcing binary content through openTextDocument and makes the fix robust across file types.

Michelin-3-star-tires · 3 months ago

Adding a fuller end-to-end summary here in case it helps consolidate the duplicate cluster.

What I verified on Windows

  • This is not limited to one file type.
  • Plain Markdown local links are the most reliable clickable format.
  • The earlier citation-style format was unstable in this rendering path and often degraded to plain text.
  • Chinese paths and file names, images, archives, compressed files, cache/metadata/dist-info files, and filenames with + / - all work once the local path is decoded/normalized and file-type routing is split correctly.

Root cause I converged on

  1. Webview markdown rendering can downgrade local resource links into external-link behavior.
  2. Percent-encoding can break the path if it is not decoded before reaching the host.
  3. A text-first opener (openTextDocument + showTextDocument) is fine for source files, but not for images, archives, or binary files.

Successful fix direction locally

  • Detect local resource URLs in the click handler instead of treating every URL as an external link.
  • Decode and normalize the path in the open-file entry point.
  • Route text files to the editor and non-text files to vscode.open.
  • Keep a fallback path and log failures.

This combination resolved the browser-jump issue for:

  • .md, .json, .py, .csv, .log, .toml
  • Chinese file and folder names
  • .png
  • .zip, .pkl.xz
  • cache / metadata / dist-info files
  • boundary names such as GMT+0 / GMT-14

I realize this may overlap with #15377, #15859, #16245, and #14946. I am leaving this note because the end-to-end reproduction and the successful routing split may still be useful for whoever consolidates the duplicate cluster.

VincentZZZZZZ08 · 3 months ago

I’m seeing what appears to be the same issue on Windows with the official OpenAI VS Code extension (openai.chatgpt).

In my case, Codex renders a local file reference as a blue clickable link in the chat UI, for example agent_backend_session_summary.zh.md, but clicking it does not open the file inside VS Code. Instead, it opens Microsoft Edge and navigates to a file+.vscode-resource.vscode-cdn.net/.../webview/... URL, which then fails with ERR_CONNECTION_RESET.

I inspected the chat DOM in VS Code Developer Tools and found that the filename is rendered as an actual <a> element, not just styled text. The relevant part looks roughly like this:

<a
  class="... underline ..."
  target="_blank"
  rel="noopener noreferrer"
>
  agent_backend_session_summary.md
</a>

What stood out is that the anchor appears to have no meaningful href value (or at least no valid local-file/navigation target), while still being rendered as a clickable external-style link with target="_blank". That seems consistent with the behavior: the link is visually rendered, but the click is not translated into “open this workspace file in VS Code”, and instead falls back to external browser navigation.

So from my debugging, this does not look like a model output formatting problem. It looks more like an extension-side link handling/navigation issue in the VS Code chat webview on Windows.

My environment:

  • OS: Windows
  • Extension: official OpenAI extension (openai.chatgpt)
  • Surface: Codex chat panel inside VS Code

Observed behavior:

  1. Codex mentions a local file in chat
  2. The filename is rendered as a blue hyperlink
  3. Clicking the link opens Edge instead of opening the file in VS Code
  4. Edge lands on a file+.vscode-resource.vscode-cdn.net/... URL and fails

This issue is highly reproducible for me. Happy to provide additional DOM screenshots / DevTools details if helpful.

APeng215 · 3 months ago

Similar issue for me on Windows OS

VincentZZZZZZ08 · 3 months ago

I’m seeing what looks like a behavior change after a recent VS Code extension update, but the underlying local file navigation issue does not appear to be fully fixed.

Previously, when Codex rendered a local file reference in chat, clicking it would open the external browser (Edge) and navigate to a broken file+.vscode-resource.vscode-cdn.net/... URL.

After the recent update, that no longer happens in my environment. However, the file link now appears to be non-clickable / unclickable in the VS Code extension. In addition, when I open the Codex app, the referenced file sometimes shows up in the right-hand sidebar, but the panel says “Unable to load file” instead of opening the file contents.

So from the user side, this looks less like a full fix and more like a behavior shift:

  • Before: wrong external navigation
  • Now: no external navigation, but the file cannot actually be opened/loaded

This makes me suspect the browser fallback may have been suppressed, but the underlying workspace-file resolution / file-open logic is still failing.

Environment:

  • Windows
  • official OpenAI VS Code extension (openai.chatgpt)
  • Codex chat inside VS Code
  • also reproducible in the Codex app side panel as “Unable to load file”
Yeyangllll · 3 months ago

I can confirm this is still broken for me on Windows with the current VS Code extension, and in my environment the local Markdown links are not just unstable, they are unusable.

Environment:

  • OS: Windows 11 10.0.26200
  • VS Code: 1.115.0
  • Extension: openai.chatgpt-26.409.20454-win32-x64

Examples tested:

  • [cso_pymmain_policy_clp.xml:1](/d:/CSO_CLP/Main/02-Backend/PYM-Main-20260409/Teld.Boss.PYM.Main.DataAccess/Maps/PYM/cso_pymmain_policy_clp.xml:1)
  • [AGENTS.md:9](/c:/Users/阳/.codex/AGENTS.md:9)

Actual result:

  • Clicking these local Markdown file links in the Codex/ChatGPT chat panel does not open the target file in VS Code.
  • In my tests, both links failed consistently.

Control result:

  • code -g "absolute_path:line" opens the same files correctly every time.

Important detail:

  • I reproduced this with both an ASCII-only repo path and a non-ASCII user-profile path.
  • So this is not only a Unicode-path edge case. It looks like the chat-panel / extension link-handling path is still broken on Windows.

Impact:

  • File references in assistant responses cannot be used as an actual navigation mechanism.
  • This is especially problematic because file references are a core part of reviewing and following code changes in the IDE workflow.

Current workaround:

  • Use code -g "absolute_path:line" instead of relying on chat-panel Markdown local file links.

Please prioritize a fix for the VS Code extension path, not only renderer-side formatting, because from the user side this currently breaks a core workflow.

flyingdoubleG · 3 months ago

same issue

APeng215 · 3 months ago

Rolling back to an older version from at least two weeks ago may solve this problem.