VS Code extension drops endLine/endColumn when opening ranged file references

What version of the IDE extension are you using?

openai.chatgpt 26.721.41059

What subscription do you have?

Not applicable for this reproduction. The extension is connected to a custom app-server-compatible backend.

Which IDE are you using?

VS Code 1.130.0

What platform is your computer?

Reproduced on Linux over VS Code Remote SSH:

Linux 5.15.120.bsk.3-amd64 x86_64 unknown

I also downloaded the official darwin-arm64 VSIX for the same extension version. The two relevant webview bundles and out/extension.js are byte-for-byte identical (matching SHA-256 hashes) between the linux-x64 and darwin-arm64 packages. Therefore the same range-dropping implementation is shipped on macOS, although I have only interactively reproduced the click behavior on Linux so far.

What issue are you seeing?

The Codex chat correctly recognizes and renders local file references that contain a line/column range, but clicking the reference opens the file with only the start position selected. The end line and end column are discarded.

For example, both of these are recognized as file references with a range:

/tmp/codex-range-test.go:4:2-4:12
/tmp/codex-range-test.go#L4C2-L4C12

The UI displays range information, but clicking either reference only places the cursor at line 4, column 2. It does not select through line 4, column 12.

This does not appear to be an app-server/model-output issue. The range is already parsed correctly by the extension webview. In extension 26.721.41059, the webview parser extracts:

path, line, column, endLine, endColumn

However, the webview open-file request is built with only:

path, cwd, target, appPath, line, column, openMode, hostId

The extension-host open handler similarly accepts only:

path, line, column, cwd, target

and creates a zero-length selection equivalent to:

const start = new vscode.Position(line - 1, column - 1);
const selection = new vscode.Range(start, start);

As a result, endLine and endColumn never reach VS Code's showTextDocument API.

What steps can reproduce the bug?

1. Create a test file:

```go
package main

func main() {
println("hello")
}
```

1. Open its containing directory in VS Code.
2. In the Codex chat, have the assistant output either of these Markdown links, replacing the path with the real absolute path:

``md
[colon range](/tmp/codex-range-test.go:4:2-4:12)
[GitHub-style range](/tmp/codex-range-test.go#L4C2-L4C12)
``

1. Confirm that Codex renders the target as a file reference with range information.
2. Click the rendered reference.

Actual result:

• The file opens.
• The cursor lands at line 4, column 2.
• The requested range through column 12 is not selected.

This reproduces with the extension connected through a custom app-server-compatible backend, but the click happens entirely after the response is rendered. The app-server is not involved in the webview-to-extension-host file-open path, and the dropped fields are visible in the installed official extension bundle.

What is the expected behavior?

When a file reference contains an end position, clicking it should pass the complete range to VS Code:

const start = new vscode.Position(line - 1, column - 1);
const end = new vscode.Position(endLine - 1, endColumn - 1);

await vscode.window.showTextDocument(document, {
  preview: false,
  selection: new vscode.Range(start, end),
});

Single-position references should continue to use a zero-length range.

Additional information

I searched existing openai/codex issues before filing. Existing reports such as #13718, #14946, #16520, and #17649 cover links that do not open at all, open in a browser, or are rendered incorrectly. I could not find an issue for this narrower case where:

1. the range is parsed and displayed correctly;
2. the file opens successfully; but
3. only the start position is forwarded to VS Code.

A likely fix requires both parts of the extension bridge:

1. Preserve endLine and endColumn in the webview's workspace-file-open request.
2. Accept them in the extension-host open handler and construct a non-empty vscode.Range.

The corresponding files in the official linux-x64 and darwin-arm64 VSIX packages for 26.721.41059 have matching SHA-256 hashes, so this is not specific to the Linux build.

No private repository names, paths, or source code are needed to reproduce the issue.