[IDE extension][Windows] Markdown file links in assistant responses lose #L line fragments

What version of the IDE extension are you using?

26.5825.51511

What subscription do you have?

ChatGPT subscription (the exact tier is not displayed in the IDE extension)

Which IDE are you using?

Visual Studio Code 1.135.0 (x64)

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

In an assistant response, a Markdown link to a local Windows file can contain a VS Code-style line fragment in the original Markdown, but the rendered link does not retain or expose the line information.

For example, the assistant outputs this Markdown:

[README.md](C:/Users/example/project/README.md#L107-L111)

The Codex chat UI renders README.md as a link, but the link target shown by the UI does not contain #L107-L111. Clicking it therefore cannot navigate to lines 107–111. The same problem occurs with a backslash-form Windows path.

This is different from user-added file references: when a file range is attached through the IDE UI, Codex receives and displays structured path and line-range information. The problem is specifically Markdown file links emitted inside assistant responses.

What steps can reproduce the bug?

1. Open the Codex sidebar in VS Code on Windows.

2. Open a workspace containing a file such as README.md with at least 111 lines.

3. Ask Codex to output an exact Markdown link to the local file with a line fragment, for example:

   [README.md](C:/Users/example/project/README.md#L107-L111)
   

4. Inspect or hover over the rendered link in the assistant response.

5. Observe that the rendered/clickable target does not retain the #L107-L111 information.

6. Click the link and observe that VS Code does not navigate to the requested line range.

What is the expected behavior?

The IDE extension should preserve the line fragment and open README.md at lines 107–111. Alternatively, it should convert the Markdown target into the same structured file-reference representation used for IDE file attachments, including the start and end lines.

Additional information

• The raw Markdown generated for the response contains #L107-L111; the line information is lost during rendering or link handling in the IDE extension.
• This appears to happen before VS Code receives the file-open request, because the rendered link target already lacks the line fragment.
• I searched existing open and closed issues using terms including markdown link, file link line, local file hyperlink, #L, and VSCode extension, and did not find the same issue.
• Related issue #41063 concerns underscores being escaped when paths are pasted into the composer. This report concerns assistant-response rendering and line fragments, so it has a different trigger and symptom.

Reproduce the issue in the Codex sidebar on VS Code using the provided C:/...#L107-L111 link, then trace the rendered-link handling. Done means the clickable target preserves the fragment or produces the equivalent structured file reference and opens lines 107–111.