Windows Codex App opens file references at the wrong line (large offset)

What version of the Codex App are you using (From About Codex dialog)?

Codex App for Windows 26.623.11225.0.

Windows package:

OpenAI.Codex_26.623.11225.0_x64__2p2nqsd0c76g0

What subscription do you have?

Not sure.

What platform is your computer?

Windows 10 Pro 10.0.19045, build 19045, 64-bit.

I see the same problem in both workflows:

• Opening a local Windows workspace directly in Codex App.
• Using Codex App on Windows while connected over SSH to a WSL2 workspace.

The WSL2 workspace is Ubuntu 20.04.5 LTS on kernel 6.18.33.1-microsoft-standard-WSL2.

What issue are you seeing?

When I click a file reference with a line number in a Codex App response, Codex opens the correct file, but the built-in code viewer scrolls to the wrong code location.

This is not just a case where the viewer fails to scroll. It does scroll, but it lands far away from the referenced target line. The offset is large enough that the opened pane can show unrelated code while still looking like navigation succeeded.

This makes line-specific references unreliable for code review and debugging, because I cannot trust that the code pane is showing the line that Codex referenced.

Since the same behavior happens for both local Windows workspaces and SSH-to-WSL2 workspaces, it does not look limited to the WSL2/SSH path.

What steps can reproduce the bug?

1. Open Codex App on Windows.
2. Open either a local Windows workspace or a workspace reached through SSH into WSL2.
3. Ask Codex to inspect or explain code so that the response contains clickable file references with explicit line numbers, for example path/to/file.ext:123.
4. Click one of those file references in the response.
5. Look at the built-in code viewer.

Actual result:

• The correct file opens.
• The viewer scrolls.
• The viewer lands at the wrong code location, with a large offset from the referenced line.

What is the expected behavior?

Clicking a file reference with a line number should open the correct file and reveal the referenced line, or at least a very small surrounding range. Ideally the target line should be focused or highlighted so it is easy to verify.

Additional information

This may be related to #28643, but the behavior I am seeing on Windows is specifically wrong-line navigation with a large offset. It is not just the pane staying at the previous/default position.

#28643 also has a comment from another user on Desktop 26.623.41415 where the pane lands at an unrelated location, so these reports may share the same underlying bug. This issue adds Windows-specific reproduction details and confirms that the problem occurs for both local Windows code and SSH-to-WSL2 workspaces.