Repository navigation
Regression on Windows in v0.4.79: absolute_path:line:column no longer opens file location (worked in v0.4.73) #13339
Description
What version of the IDE extension are you using?
v0.4.79
What subscription do you have?
Enterprise
Which IDE are you using?
VSCode
What platform is your computer?
- OS: Windows 11 (PowerShell)
- Codex CLI: v0.4.79 (broken), v0.4.73 (works)
- Path includes Japanese characters
What issue are you seeing?
Title:
Regression on Windows in v0.4.79: absolute_path:line:column no longer opens file location (worked in v0.4.73)
Body:
Summary
On Windows, Codex CLI v0.4.79 seems to break handling of file-location strings in this format:
absolute_path:line:column
This worked in v0.4.73.
Environment
- OS: Windows (PowerShell)
- Codex CLI: v0.4.79 (broken), v0.4.73 (works)
- Path includes Japanese characters
Repro
- Use v0.4.79
- Output or paste this location string:
D:\PROJECT\日本語パス\__01__\20260218\日本語プログラム名\__ユーザーテスト__\app.py:42:5 - Try to open/jump via the UI behavior that previously resolved this format.
Expected
The file opens directly and cursor jumps to line 42, column 5.
Actual
The string is treated as plain text / not resolved as a file location (jump does not work).
Regression
- v0.4.73: works
- v0.4.79: broken
Notes
This may be related to Windows path parsing and/or non-ASCII path handling.
Activity
Hsiangpo commentedon Mar 22, 2026
I can reproduce a closely related regression on Windows in the VS Code extension.
Environment
What issue are you seeing?
Absolute local file paths in Codex responses are rendered as non-clickable text in the VS Code extension.
Examples:
C:/repo/src/app.tsC:\\repo\\src\\app.tsThese paths should be clickable and open the file in VS Code, but they do not.
What steps can reproduce the bug?
What is the expected behavior?
The path should render as a clickable local file link and open in VS Code.
Additional information
I checked the installed extension locally and found that the path is being stripped too early during markdown link sanitization.
A Windows path like
C:/...is treated like a URL with ac:scheme before the local file-link handling runs, so the original path never reaches the file-link renderer.I also confirmed a local hotfix works: allowing absolute filesystem paths to bypass that sanitization step makes
C:/...paths clickable again.This looks like the same regression family as this issue, but with a more specific root cause in markdown link handling for Windows absolute paths.