[Bug]: IntelliJ IDEA not detected on macOS when the Toolbox app bundle has a version in its name

[saibotma]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

packages/contracts or packages/shared

Steps to reproduce

1. On macOS, install IntelliJ IDEA through JetBrains Toolbox so the app bundle is named with its version, e.g. ~/Applications/IntelliJ IDEA 2026.1.4.app.
2. Have the Toolbox shell script named anything other than idea. Toolbox generated idea1 for me.
3. In T3 Code, try to open a project in IntelliJ IDEA.

Expected behavior

IntelliJ IDEA is detected and opens the project.

Actual behavior

T3 Code reports that IntelliJ IDEA can't be found, even though it's installed.

resolveEditorCommand in packages/shared/src/editor.ts first checks for idea on PATH. On macOS, it then only tries these exact paths:

• {~/Applications,/Applications}/{IntelliJ IDEA,IntelliJ IDEA CE,IntelliJ IDEA Ultimate}.app/Contents/MacOS/idea (L42–L45)
• ~/Library/Application Support/JetBrains/Toolbox/scripts/idea (L58)

A Toolbox bundle with the version in its name doesn't match the first check, and a renamed script doesn't match the second. The Windows branch already handles versioned folders by listing the install directories and matching entry === name || entry.startsWith(`${name} `) (L75). macOS doesn't do this. PyCharm and Rider have the same problem.

Impact

Minor bug or occasional failure

Version or commit

T3 Code (Nightly) 0.0.46-nightly.20261005.2667. I confirmed the code path on main @ f391794a.

Environment

macOS 26.6.1, JetBrains Toolbox 3.6.2, IntelliJ IDEA 2026.1.4 (installed through Toolbox)

Workaround

In Toolbox, open IntelliJ IDEA's ⋮ menu, go to Settings → Configuration → Shell script name, and set it to idea. Then restart T3 Code.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Triage

Thanks @saibotma for the precise report, with line links and a working workaround. It matches the resolver on current main (37de6cbde65c).

What I found

• resolveEditorCommand in packages/shared/src/editor.ts only treats idea as the IntelliJ command (packages/contracts/src/editor.ts). On macOS it then tries exact paths: ~/Applications/<name>.app and /Applications/<name>.app for IntelliJ IDEA, IntelliJ IDEA CE, and IntelliJ IDEA Ultimate, plus ~/Library/Application Support/JetBrains/Toolbox/scripts/idea.
• IntelliJ IDEA 2026.1.4.app matches none of those bundle names, because the macOS branch never lists the Applications directories. The Windows branch does, and accepts entry === name || entry.startsWith(${name} ), which is why WebStorm 2026.2 is covered there (and in apps/server/src/process/externalLauncher.test.ts). The darwin fixtures only use an exact WebStorm.app.
• A Toolbox script named idea1 misses the same way: the PATH check only looks up idea, and the scripts fallback only checks that one filename. Toolbox generates a unique script name when more than one version is installed, so this layout is fairly common.
• The two checks don't cover for each other, so an install with both a versioned bundle and a non-idea script isn't found at all. Renaming the script to idea works because it hits the scripts fallback.
• The same exact-name construction is shared by the other JetBrains editors, including PyCharm and Rider. fix: intellij not being visible even though it's installed #1828 and fix: detect installed editors outside PATH #12439 are the earlier "installed but not on PATH" work; fix: detect installed editors outside PATH #12439 added these exact paths.

Likely fix area

The darwin branch of resolveEditorCommand. One option is to list ~/Applications and /Applications and accept <name>.app or <name> <version>.app with the same prefix rule Windows uses, still launching Contents/MacOS/<command>. That would cover the other JetBrains apps in the same pass. Separately, the Toolbox scripts lookup only checks the canonical command name on every platform, which could be handled here or in a follow-up. A darwin test next to the existing Windows WebStorm 2026.2 case would help lock in the behavior.

A maintainer will decide on the fix direction.