File reference line links are unreliable in Codex Desktop App

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

• #27348

Powered by Codex Action

Still reproducible in Codex Desktop 26.623.41415 (build 4505) on macOS 26.5.1 (Apple Silicon).

This also affects inline review code comments.

Steps to reproduce

1. In a Codex chat, click an assistant-generated file reference with an explicit line number, such as containerEnterChain.js:63.
2. Observe the right-side code/review pane.
3. Repeat with a file link associated with an inline code-comment annotation.

Actual behavior

• The file opens, but the pane lands at an unrelated location instead of the referenced line.
• For code-comment links, the associated inline comment is not visible and cannot be found by scrolling.
• The problem persists after restarting Codex and checking for updates.

Expected behavior

• The pane should scroll to and focus the exact referenced line.
• Any anchored inline review comment should render at that line.

This makes line-anchored review feedback effectively unusable even though the file itself opens.

same here

I can reproduce this on Codex Desktop for macOS as well.

Concrete repro from a recent thread:

1. The assistant response contains a clickable file reference: codex-rs/cli/src/main.rs (line 94).
2. I click that file reference.
3. Codex opens the correct file in the side file viewer, but the viewer lands around line 3994 instead of line 94.

This is not just a case where the viewer stays at the previous/default scroll position. The file opens and the viewer lands far away from the referenced target line, so navigation looks successful at first glance but shows unrelated code.

Expected: clicking a file reference with a line number should open the file and reveal/focus the referenced line, or at least a small surrounding range.

Actual: the correct file opens, but the line-specific scroll target is wrong by a large offset, making Codex's line-number references unreliable for code inspection.

This looks related to #30805, but my repro is on macOS Desktop rather than Windows.

here is a repro video,
https://github.com/user-attachments/assets/3f45cc65-2105-4340-bd49-4cb7785b1730

Still reproducible in Codex Desktop on macOS.

Concrete repro:

1. Assistant output contains a clickable file reference like:

controller/user.go (line 992) targeting /Users/.../newapi/controller/user.go:992

1. Click the link.
2. Codex opens the correct file, but the code viewer lands at an unrelated line instead of line 992.

This is not just preserving the previous scroll position; the viewer appears to navigate, but to the wrong offset.

The open-source TUI parser already handles :line, :line:col, and #L... suffixes in codex-rs/tui/src/markdown_render.rs, so this looks like a Desktop App file-reference click/editor synchronization issue.

Note that the correct line is highlighted, but the file viewer fails to scroll to that line.

For me, not only does the file-viewer not open to a position which I can review the referenced line, I cannot scroll the viewer window at all.

The problem goes deeper than that, and is reproducible as follows:

1. Open an unanchored local-file link, for example:

./Documents/myProgram.go

1. Confirm the editor opens at the top and scrolls normally.
2. Close the editor tab.
3. Open an anchored link to the same file, for example:

./Documents/myProgram.go:655

1. The editor opens around 50 lines beyond that point (ln 705), but scrolling upward bounces and does not allow navigation beyond about line 704.
2. Close the tab and reopen the unanchored file link. It now reopens at the anchored position and remains non-scrollable.

Restarting the app clears the condition until an anchored link is opened again. I installed the latest available update and reproduced the issue afterward.

Expected behaviour: an anchored link should position the editor at the requested line while preserving normal scrolling; an unanchored link should open normally and should not inherit a broken anchored state.

Actual behaviour: opening an anchored local-file link appears to cache a stuck scroll position for that file path, including after the editor tab is closed.