Codex APP（windows）can not open jetbrains IDEA

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

• #13775
• #12988
• #12472

Powered by Codex Action

I encountered the same issue, but my error message is different from yours.

<img width="958" height="489" alt="Image" src="https://github.com/user-attachments/assets/f3822955-7e12-410f-b641-6932f2947ac9" />

Now it will jump to the sidebar.

Now it will jump to the sidebar.现在它会跳转到侧边栏。

I just tried it, the latest version of codex on Windows has no new optimizations

> Now it will jump to the sidebar.现在它会跳转到侧边栏。 I just tried it, the latest version of codex on Windows has no new optimizations我刚试了一下，Windows 上的最新版 Codex 并没有任何新的优化。

Did you just update? On Windows, it now jumps to the sidebar of the Codex app page, even with the latest version. However, on Mac, it cannot jump to JetBrains IDEA, which worked fine before the update.

> > Now it will jump to the sidebar.现在它会跳转到侧边栏。 > > > I just tried it, the latest version of codex on Windows has no new optimizations我刚试了一下，Windows 上的最新版 Codex 并没有任何新的优化。 Did you just update? On Windows, it now jumps to the sidebar of the Codex app page, even with the latest version. However, on Mac, it cannot jump to JetBrains IDEA, which worked fine before the update.

I just went to the Microsoft Store to check the Codex version to ensure it's up to date, but the IDEA icon still isn't displaying properly
<img width="376" height="487" alt="Image" src="https://github.com/user-attachments/assets/a4617bc3-f54d-4e55-876b-08023eb057b7" />

> > > Now it will jump to the sidebar.现在它会跳转到侧边栏。 > > > > > > I just tried it, the latest version of codex on Windows has no new optimizations我刚试了一下，Windows 上的最新版 Codex 并没有任何新的优化。 > > > Did you just update? On Windows, it now jumps to the sidebar of the Codex app page, even with the latest version. However, on Mac, it cannot jump to JetBrains IDEA, which worked fine before the update. I just went to the Microsoft Store to check the Codex version to ensure it's up to date, but the IDEA icon still isn't displaying properly <img alt="Image" width="376" height="487" src="https://private-user-images.githubusercontent.com/107749290/576921665-a4617bc3-f54d-4e55-876b-08023eb057b7.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzU4OTk0MTAsIm5iZiI6MTc3NTg5OTExMCwicGF0aCI6Ii8xMDc3NDkyOTAvNTc2OTIxNjY1LWE0NjE3YmMzLWY1NGQtNGU1NS04NzZiLTA4MDIzZWIwNTdiNy5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwNDExJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDQxMVQwOTE4MzBaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT02Mjk4Yjc1YThlMmM4YjE3ZWNmZTdjZWQ0MTU0OGM0M2UxNjhjOGU0ZmQ1M2IxYjE1NjVmMmI3YjgwMWFiZDFlJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZyZXNwb25zZS1jb250ZW50LXR5cGU9aW1hZ2UlMkZwbmcifQ.fFqHTPSkmD8Dug-_IcK-bkmn-cvQFgbW0Zd7jQbFKW8">

<img width="1064" height="351" alt="Image" src="https://github.com/user-attachments/assets/3b0b40c6-1364-4d38-b4de-f6fce0462ed1" />
yes，Now both Mac and Windows just stay here.

Yes, many people have raised this issue, but the official Codex team doesn't fix it.😅

I can reproduce what looks like the same underlying issue on Windows, and I have some additional findings that may help narrow it down.

What I observed:

• This is not limited to IntelliJ IDEA / PyCharm. I can reproduce it with WebStorm and Rider as well.
• It reproduces on three different Windows machines.
• If no JetBrains IDE instance exits launching from Codex works.
• If one or more IDE instance already existed, launching from Codex fails.
• Manually launching the exact same IDE executable from PowerShell works fine

Important details:

• I tested different IDE versions(2026.01 2025.03 2025.02) and this still reproduces.
• Switching the IDE boot runtime to external OpenJDK 21 can solve the issue
• Moreover, the process security context is different.
• In Process Explorer, the failing Codex-triggered JetBrains process shows an incomplete security view compared with the successful manually launched process, including Logon Session = n/a.

This makes me suspect the problem is not just “JetBrains cannot open”, but specifically a Windows compatibility issue between:

1 Codex App’s sandbox context
2 JetBrains’ single-instance activation IPC path under the default runtime

I can reproduce what looks like the same underlying issue on Windows, and I have some additional findings that may help narrow it down. What I observed: This is not limited to IntelliJ IDEA / PyCharm. I can reproduce it with WebStorm and Rider as well. It reproduces on three different Windows machines. If no JetBrains IDE instance exits launching from Codex works. If one or more IDE instance already existed, launching from Codex fails. Manually launching the exact same IDE executable from PowerShell works fine Important details: I tested different IDE versions(2026.01 2025.03 2025.02) and this still reproduces. Switching the IDE boot runtime to external OpenJDK 21 can solve the issue Moreover, the process security context is different. * In Process Explorer, the failing Codex-triggered JetBrains process shows an incomplete security view compared with the successful manually launched process, including Logon Session = n/a. This makes me suspect the problem is not just “JetBrains cannot open”, but specifically a Windows compatibility issue between: 1 Codex App’s sandbox context 2 JetBrains’ single-instance activation IPC path under the default runtime

Yes, I found it might be a compatibility issue with Windows, not related to the JDK version. I'm using JDK 21, but the problem still exists. However, my friend's Codex APP on Windows can display the IDEA icon normally. But the Antigravity icon still cannot display properly.

also experiencing this bug

I also encountered the same bug, unable to open JetBrains IDE. Please make sure the official team fixes it

Same with JetBrains IDEs

Same with Android Studio

Antigravity has the same issue

Adding a more detailed Windows/IntelliJ reproduction and the fix/workaround that made it reliable locally.

Environment

• Codex Windows app package: OpenAI.Codex_26.519.2736.0_x64__2p2nqsd0c76g0
• Codex product version from Codex.exe: 26.519.22136
• OS: Windows 11 Pro 10.0.26200 x64
• IDE: IntelliJ IDEA 2026.1.2 stable
• IDEA path: C:\Users\<user>\AppData\Local\Programs\IntelliJ IDEA\bin\idea64.exe
• JetBrains Runtime shown in the failure dialog: 25.0.2+1-b329.117 amd64

Repro

1. Start IntelliJ IDEA with the relevant project/workspace already open.
2. In Codex Desktop on Windows, right-click a blue file link in chat.
3. Choose Open with > IntelliJ IDEA.
4. Codex invokes the Windows app association / handler for IntelliJ.
5. A second idea64.exe process is launched with the file path argument instead of reliably activating the already-running IDE instance.
6. IDEA shows an internal error dialog:

com.intellij.platform.ide.bootstrap.DirectoryLock$CannotActivateException: Process "C:\Users\<user>\AppData\Local\Programs\IntelliJ IDEA\bin\idea64.exe" (...) is still running and does not respond.

Suppressed: java.net.SocketException: Invalid argument: bind
    at java.base/sun.nio.ch.UnixDomainSockets.bind0(Native Method)
...
Suppressed: java.net.SocketException: Invalid argument: connect
    at java.base/sun.nio.ch.UnixDomainSockets.connect0(Native Method)
...
JRE: 25.0.2+1-b329.117 amd64 (JetBrains s.r.o.)

The issue also affects the Open with icon: when the Windows handler points at a shim or non-standard launcher, Codex can show a generic executable icon instead of the real IntelliJ IDEA icon.

Local instrumentation

I put a small idea64.exe shim first on PATH and let Codex discover/use it. The shim logged that Codex really was invoking the opener from the Codex process:

parent=Codex event=invoked args=C:\Users\<user>\Documents\git\ePC-SAFT\AGENTS.md

When that shim simply delegated to the real IDEA launcher, the bug still reproduced: a child process like this was created and then failed with the DirectoryLock$CannotActivateException above:

"C:\Users\<user>\AppData\Local\Programs\IntelliJ IDEA\bin\idea64.exe" C:\Users\<user>\Documents\git\ePC-SAFT\AGENTS.md

When the shim instead opened the file through the already-running IDE/index bridge, the same Codex Open with > IntelliJ IDEA action succeeded and did not spawn a second IDEA process:

parent=Codex event=invoked args=C:\Users\<user>\Documents\git\ePC-SAFT\AGENTS.md
parent=Codex event=opened-via-intellij-index: C:\Users\<user>\Documents\git\ePC-SAFT::AGENTS.md

That points to the core problem: the current Codex Windows Open with flow is relying on a generic Windows app association / launcher path that is not a reliable "open this file in the already-running JetBrains IDE" integration.

What Codex could fix

Recommended Codex-side fix:

1. Add an explicit external editor command template, not just Windows Open with, for file links. For example:

command: C:\path\to\idea64.exe
args: --line {line} --column {column} {file}
icon: C:\path\to\idea.ico

1. Preserve structured {file}, {line}, {column}, and optionally {workspace} placeholders instead of relying on one opaque shell/file association handoff.

1. For JetBrains IDEs on Windows, prefer an activation path that targets the running IDE instance or a known JetBrains command-line launcher contract, rather than launching the GUI executable with only the file path.

1. If Codex exposes custom/open-with commands, allow an icon override or use the selected shortcut's icon location. Otherwise shims and custom launchers show up as generic icons.

1. If the built-in JetBrains MCP / IDE bridge is available, use it for file opening where possible instead of the OS app association. In my local workaround, directly calling the IDE bridge to open the file solved the issue.

What JetBrains may need to fix

JetBrains may also have a launcher activation bug here: idea64.exe <file> should either open the file in the already-running instance or fail gracefully. Instead, on this Windows/JBR combination the activation path hits DirectoryLock$CannotActivateException with suppressed Unix domain socket bind/connect Invalid argument errors.

Even if JetBrains fixes that, Codex would still benefit from a first-class external editor command/template because Windows app associations are too indirect for reliably opening file+line targets in already-running IDEs.

For anyone looking for an easy workaroud, I noticed that Codex now has an "Open in Default App" option. I'm not sure how long it's been there, I don't remember it being there last time I tried this.

If you associate the file type you're trying to open with whatever JetBrains IDE you're using, this actually works and opens the file almost instantly.

How is this issue of seeking help being resolved? Has Codex abandoned the rider?

I am not a Java developer, so my conclusions may not be perfectly accurate, but based on my testing it looks like there may be an issue in JetBrainsRuntime related to opening file links on Windows from Codex.

I originally noticed this problem in Codex, but I have also seen similar behavior in other applications when trying to open a specific file using any JetBrains IDE.

The issue happens with different JetBrains IDEs:

• WebStorm
• PyCharm
• IntelliJ IDEA

The exact IDE does not seem to matter. The error remains the same.

What I tested

1. On Windows, I downloaded four different JDK/JBR builds for testing:

Oracle JDK:

• jdk-25.0.3
• jdk-21.0.11

From:

• https://www.oracle.com/tw/java/technologies/downloads/

JetBrainsRuntime:

• jbr_jcef-25.0.3-windows-x64-b496.62
• jbr_jcef-21.0.11-windows-x64-b1163.116

From the official JetBrainsRuntime releases:

• https://github.com/JetBrains/JetBrainsRuntime/releases

1. I extracted all JDK/JBR folders into:

``text
C:\Program Files\Java
``

1. Since I tested this with WebStorm, I created the following file:

``text
C:\Users\iliya\AppData\Roaming\JetBrains\WebStorm2026.1\webstorm64.exe.jdk
``

This forces WebStorm to use a specific JDK/JBR.

The file contains only the path to the runtime, for example:

``text
C:\Program Files\Java\jdk-25.0.3
``

1. I made sure WebStorm was fully closed, then started it again.

After that, I checked:

``text
Help > About
``

to confirm that WebStorm was actually using the JDK/JBR specified in webstorm64.exe.jdk.

1. With Oracle JDK, for example:

``text
C:\Program Files\Java\jdk-25.0.3
``

I went to Codex and clicked Open With, or simply Open when Codex was configured with:

``text
Settings > Default open destination = WebStorm
``

In this case everything worked correctly. The file opened in WebStorm and there was no error.

1. Then I changed the contents of:

``text
C:\Users\iliya\AppData\Roaming\JetBrains\WebStorm2026.1\webstorm64.exe.jdk
``

to one of the JetBrainsRuntime builds, for example:

``text
C:\Program Files\Java\jbr_jcef-21.0.11-windows-x64-b1163.116
``

or:

``text
C:\Program Files\Java\jbr_jcef-25.0.3-windows-x64-b496.62
``

1. I opened WebStorm again and confirmed in:

``text
Help > About
``

that the runtime had changed.

1. After that, trying to open the same file from Codex using JetBrains again produced the same error.

Result

With Oracle JDK:

C:\Program Files\Java\jdk-25.0.3

or:

C:\Program Files\Java\jdk-21.0.11

opening files from Codex works correctly.

With JetBrainsRuntime:

C:\Program Files\Java\jbr_jcef-21.0.11-windows-x64-b1163.116

or:

C:\Program Files\Java\jbr_jcef-25.0.3-windows-x64-b496.62

the issue appears again.

Important note

This is not a real workaround or solution, because running a JetBrains IDE with a regular Oracle JDK is not ideal. For example, the IDE opens with a visible window frame, and the fonts also looked different to me.

However, I think this is a strong indication that the problem may be related to JetBrainsRuntime specifically, rather than Codex or the JetBrains IDE itself.

+1

Same issue happened in Pycharm and Rider

I am not a Java developer, so my conclusions may not be perfectly accurate, but based on my testing it looks like there may be an issue in JetBrainsRuntime related to opening file links on Windows from Codex. I originally noticed this problem in Codex, but I have also seen similar behavior in other applications when trying to open a specific file using any JetBrains IDE. The issue happens with different JetBrains IDEs: WebStorm PyCharm IntelliJ IDEA The exact IDE does not seem to matter. The error remains the same. ### What I tested 1. On Windows, I downloaded four different JDK/JBR builds for testing: Oracle JDK: jdk-25.0.3 jdk-21.0.11 From: https://www.oracle.com/tw/java/technologies/downloads/ JetBrainsRuntime: jbr_jcef-25.0.3-windows-x64-b496.62 jbr_jcef-21.0.11-windows-x64-b1163.116 From the official JetBrainsRuntime releases: * https://github.com/JetBrains/JetBrainsRuntime/releases 2. I extracted all JDK/JBR folders into: `` C:\Program Files\Java ` 3. Since I tested this with WebStorm, I created the following file: ` C:\Users\iliya\AppData\Roaming\JetBrains\WebStorm2026.1\webstorm64.exe.jdk ` This forces WebStorm to use a specific JDK/JBR. The file contains only the path to the runtime, for example: ` C:\Program Files\Java\jdk-25.0.3 ` 4. I made sure WebStorm was fully closed, then started it again. After that, I checked: ` Help > About ` to confirm that WebStorm was actually using the JDK/JBR specified in webstorm64.exe.jdk. 5. With Oracle JDK, for example: ` C:\Program Files\Java\jdk-25.0.3 ` I went to Codex and clicked Open With, or simply Open when Codex was configured with: ` Settings > Default open destination = WebStorm ` In this case everything worked correctly. The file opened in WebStorm and there was no error. 6. Then I changed the contents of: ` C:\Users\iliya\AppData\Roaming\JetBrains\WebStorm2026.1\webstorm64.exe.jdk ` to one of the JetBrainsRuntime builds, for example: ` C:\Program Files\Java\jbr_jcef-21.0.11-windows-x64-b1163.116 ` or: ` C:\Program Files\Java\jbr_jcef-25.0.3-windows-x64-b496.62 ` 7. I opened WebStorm again and confirmed in: ` Help > About ` that the runtime had changed. 8. After that, trying to open the same file from Codex using JetBrains again produced the same error. ### Result With Oracle JDK: ` C:\Program Files\Java\jdk-25.0.3 ` or: ` C:\Program Files\Java\jdk-21.0.11 ` opening files from Codex works correctly. With JetBrainsRuntime: ` C:\Program Files\Java\jbr_jcef-21.0.11-windows-x64-b1163.116 ` or: ` C:\Program Files\Java\jbr_jcef-25.0.3-windows-x64-b496.62 `` the issue appears again. ### Important note This is not a real workaround or solution, because running a JetBrains IDE with a regular Oracle JDK is not ideal. For example, the IDE opens with a visible window frame, and the fonts also looked different to me. However, I think this is a strong indication that the problem may be related to JetBrainsRuntime specifically, rather than Codex or the JetBrains IDE itself.

Perhaps you're right; this isn't entirely Codex's fault, as my friend's Windows computer can still launch JetBrains series software normally through Codex

I found a workaround that works for me on Windows 11 Pro with Rider 2025.3 and Codex Desktop.

Symptom:

• Codex "Open in Rider" triggers Rider's dialog: rider64.exe is still running and does not respond.
• Running the same command manually from PowerShell works, for example:

rider64.exe --line 1 --column 1 "D:\Perforce\xujie_partopia_main_backup\Client\AGENTS.md"

What did not fix it:

• Putting a wrapper named rider64.exe earlier on PATH. Codex still resolved the real JetBrains install path.
• Pretending to be WebStorm by adding a fake webstorm64.exe did make Codex call my wrapper, but if that wrapper directly launched the real Rider process, Rider still showed the same popup.

What finally worked:

1. In Codex, set the preferred editor to WebStorm.
2. Put a fake webstorm64.exe earlier on PATH, for example under %LOCALAPPDATA%\Microsoft\WindowsApps or %USERPROFILE%\.local\bin.
3. Make that fake webstorm64.exe only enqueue the requested open-file arguments and exit with code 0. Do not launch Rider directly from this process.
4. Start a separate background helper from a normal PowerShell/user session. This helper watches the queue and launches the real Rider executable with the queued args.

Pseudo-code:

webstorm64.exe wrapper:
  write args to %LOCALAPPDATA%\CodexRiderWrapper\requests\*.req
  exit 0

background helper, started separately from PowerShell:
  loop:
    read queued args
    Process.Start(real rider64.exe, args, UseShellExecute=true)

This seems to matter because the actual Rider launch is no longer a child/descendant of the Codex desktop app. It happens from a normal user-started helper process instead. After switching to this queue + helper approach, Codex file links open in Rider successfully, including line/column arguments, and the rider64.exe is still running and does not respond dialog no longer appears.

It would be great if Codex supported a custom editor command / .bat opener, or launched JetBrains IDE targets through a detached shell/user-context helper on Windows.

Portable build for the queue + helper workaround described above.

Usage:

1. Edit codex-rider-wrapper.ini and set targetExe to your local rider64.exe.
2. Run start-server.bat or webstorm64.exe --server.
3. Add the extracted folder to your user PATH.
4. In Codex, choose WebStorm as the preferred editor.

Attached zip:

codex-rider-wrapper-lite-trimmed-20260630-205315.zip