›_ Codex Issues
Codex Issues / #23238

Codex Desktop on Windows repeatedly launches IntelliJ IDEA from project path click and triggers JetBrains DirectoryLock error

Open 💬 2 comments Opened May 18, 2026 by lzbobo

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

26.513.40821

What subscription do you have?

pro

What platform is your computer?

_No response_

What issue are you seeing?

Environment:

  • OS: Windows
  • Codex Desktop: 26.513.40821
  • Codex CLI/runtime: 0.131.0-alpha.9
  • IntelliJ IDEA: 2025.3
  • IDEA path: D:\IntelliJ IDEA 2025.3\bin\idea64.exe
  • Project path: D:\workspace\xuanwu-contract-sign

Steps to reproduce:

  1. Open Codex Desktop on Windows.
  2. Configure/open target for the project path to IntelliJ IDEA.
  3. Click the project directory/path address in Codex.
  4. IDEA opens successfully if it is not already running.
  5. Click the same project directory/path address again while IDEA is already running.

Actual result:
Codex launches idea64.exe again and IntelliJ IDEA shows an internal error:

com.intellij.platform.ide.bootstrap.DirectoryLock$CannotActivateException:
Process "D:\IntelliJ IDEA 2025.3\bin\idea64.exe" is still running and does not respond.

Suppressed exceptions include:
java.net.SocketException: Invalid argument: bind
java.net.SocketException: Invalid argument: connect

Expected result:
If IntelliJ IDEA is already running for that project, Codex should either:

  • activate/focus the existing IDEA window,
  • use JetBrains Toolbox/IDE protocol safely,
  • or avoid launching a second IDEA process from the project path click.

Additional findings:

  • The IDEA process is alive and responding.
  • Running Start-Process "D:\IntelliJ IDEA 2025.3\bin\idea64.exe" "D:\workspace\xuanwu-contract-sign" twice from PowerShell did not reproduce the issue.
  • Simulating Node spawn with the same executable/path also worked.
  • The issue appears specific to Codex Desktop's project path click/open-target flow or persisted open target state.
  • Codex persisted state contains:

"open-in-target-preferences": {"global":"intellij","perPath":{"D:\\workspace\\xuanwu-contract-sign":"intellij"}}

  • Changing the persisted JSON to fileManager can be overwritten by the running Codex app on exit/restart.

Impact:
Repeatedly clicking the project directory address in Codex causes a scary IntelliJ internal error and makes the Codex directory link unreliable when IntelliJ is selected as the open target.

What steps can reproduce the bug?

Codex Windows 客户端点击项目目录地址会重复启动 IDEA，而不是激活已有 IDEA，导致 IDEA 2025.3 报 DirectoryLock$CannotActivateException。这是 Codex 打开目标逻辑和 JetBrains 单实例机制的兼容问题。

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

2 Comments

showms · 2 months ago

I dug into the current open-source repo to narrow the likely scope of this bug.

What I found:

  • In the current Rust config surface, the only visible file-opening abstraction is file_opener, described as a URI-based file opener for clickable file citations.
  • The supported openers currently exposed in UriBasedFileOpener are only:
  • vscode
  • vscode-insiders
  • windsurf
  • cursor
  • none
  • I do not see an IntelliJ / IDEA target in that enum, and I also do not see desktop.open-in-target-preferences, Open in IDEA, intellij, or idea64 references in the open-source repo.

Relevant code pointers:

  • codex-rs/config/src/types.rs (UriBasedFileOpener)
  • codex-rs/config/src/config_toml.rs (file_opener)
  • codex-rs/core/src/config/mod.rs (defaulting file_opener to VsCode)

That makes me suspect this Windows "Open in IDEA" behavior is either:

  1. implemented in a desktop-app-specific layer that is not represented in the current open-source code path I inspected, or
  2. routed through a different app integration path than the URI-based opener surface above.

Separately, I can still reproduce the user-visible failure pattern:

  • opening IDEA works when IDEA is not already running
  • opening again while IDEA is already running appears to try to start another IDEA process
  • IntelliJ then fails with DirectoryLock$CannotActivateException instead of reusing/focusing the existing instance

If helpful, I can continue from here and post either:

  1. a more precise code-path analysis if a maintainer can point to the desktop-app layer that owns "Open in IDEA" on Windows, or
  2. a minimal proposed fix outline once the intended ownership/path is confirmed

If this aligns with the team’s intended direction, would you be open to an invited PR for this issue?

xujiezhige · 1 month ago

这个方法可以解决（this url can solve thie problem)
https://github.com/openai/codex/issues/13937#issuecomment-4843425233