Repository navigation
[Bug]: JetBrains file links can open in the wrong project #5885
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
- Open checkout/worktree A of a repository in IntelliJ IDEA.
- In T3 Code, open a thread whose effective workspace is checkout/worktree B of the same repository, with B not already open in IntelliJ.
- Click a positioned file link from chat, a diff, a Git file action, or a terminal link, for example:
/abs/worktree-b/src/File.java:168:4 - Observe which IntelliJ project owns the opened editor tab.
T3 currently launches the file without passing the thread's effective project/worktree root:
idea --line 168 --column 4 /abs/worktree-b/src/File.java
Expected behavior
T3 should explicitly pass the effective project root it already knows, followed by the existing positioned file arguments:
idea /abs/worktree-b --line 168 --column 4 /abs/worktree-b/src/File.java
IntelliJ should open or reuse worktree B as the project, then navigate to the requested line and column.
The project root should be carried explicitly in the editor-launch request rather than rediscovered from the file path, so this remains correct for non-Git projects and remote environments.
I expect this command structure should work for all JetBrains products, but I only verified with the ones I use, IntelliJ and C Lion
Actual behavior
Because only the file is passed, IntelliJ has to infer project ownership. With multiple related checkouts open, or when the intended worktree is not open yet, it can reuse the wrong project, open the file in LightEdit, or fail while trying to start another IDE instance.
The current launch contract contains the target path and editor ID, but not the T3 project/worktree root.
Impact
IntelliJ opens the file in the wrong project window. Sometimes you get an error from intellij.
Version or commit
main-compatible checkout @ 02f4ce5
Environment
macOS, T3 Code web/desktop host, IntelliJ IDEA; especially visible with multiple Git worktrees
Logs or stack traces
# Current argument shape
idea --line 168 --column 4 /abs/worktree-b/src/File.java
# Desired argument shape
idea /abs/worktree-b --line 168 --column 4 /abs/worktree-b/src/File.javaScreenshots, recordings, or supporting files
No response
Workaround
A PATH wrapper around idea can infer the Git or .idea root from a single file target and insert that root before the existing arguments.
Additional context
T3 already parses :line:column targets for JetBrains editors and emits --column when a column is present. That behavior is not missing; it should be preserved and covered together with the project-root case.
Related but not duplicate:
- Open project in IntelliJ #657 / feat: support IntelliJ IDEA open-in launch #1673 added IntelliJ IDEA and
--line/--columnlaunch support. - [Feature]: Open in — a global default app plus a per-project override #5090 proposes choosing a different default editor per project; this bug is about selecting the correct project inside the chosen JetBrains IDE.
JetBrains CLI reference: https://www.jetbrains.com/help/idea/opening-files-from-command-line.html
Activity
dain commentedon Aug 9, 2026
I had Codex implement this, and it took only 8 minutes. The change looks pretty simple to me, but I'm not a front end dev, so it might be better for you to prompt it instead. Let me know if you want help on this.
maslinedwin commentedon Aug 16, 2026
Opened a fix in #7194.
JetBrains launches now include the thread’s known workspace/worktree root when T3 already has it, so the CLI becomes:
instead of
idea --line 168 --column 4 /abs/worktree-b/src/File.java.--columnis still omitted when no column is present, and the old argument shape is used if no project root is on the launch request. The root is taken from the existing workspace cwd, not rediscovered from the file path.