[Windows Desktop] VS Code on a secondary drive is not detected; “Default app” opens it with a generic name/icon

What version of the Codex App are you using?

26.715.4045.0 (Microsoft Store package)

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Windows 11 x64 (Microsoft Windows NT 10.0.26100)

What issue are you seeing?

Codex Desktop does not show a dedicated VS Code entry in the Open in menu when VS Code is installed on a secondary drive.

The menu only shows:

• Visual Studio
• Default app
• Terminal
• IntelliJ IDEA

Selecting Default app successfully opens the file/folder in VS Code because VS Code is the Windows default application. However, Codex still displays the generic label Default app and the generic File Explorer icon instead of the actual application name and VS Code icon.

VS Code itself is installed correctly and works normally outside Codex.

Anonymized install path:

D:\Users\<user>\AppData\Local\Programs\Microsoft VS Code\Code.exe

VS Code version:

1.129.1
8a7abeba6e03ea3af87bfbce9a1b7e48fed567b8
x64

Evidence

The command-line registration is valid:

where.exe code
D:\Users\<user>\AppData\Local\Programs\Microsoft VS Code\bin\code
D:\Users\<user>\AppData\Local\Programs\Microsoft VS Code\bin\code.cmd

code --version succeeds.

The Windows App Paths entry is also correct:

HKCU\Software\Microsoft\Windows\CurrentVersion\App Paths\Code.exe
(Default) = D:\Users\<user>\AppData\Local\Programs\Microsoft VS Code\Code.exe

The normal VS Code uninstall record exists and points to the same installation.

The Codex main process receives a PATH containing the VS Code bin directory, and PATHEXT contains .CMD.

A controlled comparison using Codex's desktop.custom_file_handlers configuration showed:

• A handler whose command was C:\Windows\System32\notepad.exe appeared in the Open in menu.
• The equivalent handler whose command was the secondary-drive Code.exe did not appear.
• A C-drive directory junction pointing to the D-drive VS Code installation did not make the built-in VS Code entry appear.

This suggests that the Open-in discovery worker considers the D-drive VS Code command unavailable even though Windows, the shell, PATH, and the registry all resolve it correctly.

Inspection of the packaged desktop code also suggests that:

• the built-in VS Code detector primarily uses code from PATH and a small set of standard installation roots;
• it does not fall back to the Windows App Paths\Code.exe or uninstall registration;
• the systemDefault target uses a hard-coded Default app label and generic icon rather than resolving the actual associated application's metadata.

What steps can reproduce the bug?

1. Install VS Code for the current user under a secondary-drive path such as:

D:\Users\<user>\AppData\Local\Programs\Microsoft VS Code.

1. Ensure its bin directory is in the user PATH.
2. Confirm that where.exe code and code --version work.
3. Confirm that HKCU\...\App Paths\Code.exe points to the valid Code.exe.
4. Set VS Code as the Windows default application for the relevant source files.
5. Fully quit all Codex/ChatGPT desktop processes and restart Codex.
6. Open a local project and inspect the Open in menu.

Actual behavior

• No dedicated VS Code entry is shown.
• Default app opens VS Code successfully.
• The menu continues to display the generic name and icon.

Expected behavior

At least one of the following should happen:

1. Codex should detect VS Code through the valid PATH entry regardless of the drive on which it is installed.
2. On Windows, discovery should fall back to App Paths\Code.exe, uninstall metadata, or another standard Windows application registration mechanism.
3. If Codex uses the Windows default application, the menu should resolve and display the actual application's name and icon instead of always showing Default app.

Additional information

• Reinstalling Codex is unlikely to affect the path-specific discovery behavior.
• VS Code does not need repair or reinstallation; it launches normally through Windows and the terminal.
• This appears related to, but distinct from, #18623. That report concerns launching an already detected VS Code target; this report concerns VS Code not being exposed as an available target in the first place.