codex - 💡(How to fix) Fix Codex Desktop: normal file-reference clicks open side pane instead of configured IDE target [1 comments, 2 participants]

What version of the Codex App are you using?

Codex Desktop 26.409.20454 / build 1462

What platform is your computer?

macOS 26.4.1 (25E253), arm64

What issue are you seeing?

Normal clicks on markdown file references in Codex Desktop open the built-in Codex side pane instead of the configured IDE target.

The right-click/context-menu path still opens the same file reference in the configured IDE correctly. In my case the configured open target is VS Code, and the context-menu action works, but a normal click goes into Codex's side pane.

This makes normal file references much slower to use because every link requires right-clicking/context-menuing instead of a single click.

This looks related to #17526, but the issue here is not only that the side pane misses the referenced line. The bigger problem is that normal click no longer respects the configured IDE-opening behavior/path, while the context menu still does.

What steps can reproduce the bug?

1. Configure Codex Desktop to open files in an IDE target such as VS Code.
2. Ask Codex to reference a file path with a line number in a response.
3. Click the file reference normally.
4. Observe that Codex opens the built-in side pane.
5. Right-click the same reference and choose the IDE/open-file action.
6. Observe that the configured IDE opens the target file correctly.

What is the expected behavior?

Either:

• Normal file-reference clicks should use the configured IDE target, matching the context-menu path, or
• Codex Desktop should expose a setting that lets users choose whether normal clicks open the Codex side pane or the configured IDE.

Why this matters

For users working primarily in an IDE, opening code references in the side pane is a regression. The context-menu path proves that Codex still has a valid IDE-opening path; it is just not used by normal clicks.

Additional investigation

I investigated a local patch as a workaround. The apparent renderer click branch lives in app.asar and can be altered so the side-pane branch is skipped, but patching the desktop app bundle is not a viable workaround:

• Modifying app.asar trips Electron's runtime ASAR validation.
• Even after recomputing the visible per-file ASAR integrity hash and updating Info.plist, Electron still crashed with:

Failed to validate block while ending ASAR file stream

• Re-signing the app bundle also creates macOS signing/TCC/keychain issues because the app is no longer signed by OpenAI.

So this probably needs a first-party fix or a supported setting rather than users patching the local desktop bundle.