Every Agent Gets Its Own Git Worktree: Inside JetBrains' Incubator IDE

JetBrains has a habit of shipping tools that assume you already know what you are doing. ThinkRail is different, and the difference is in one sentence of its README: open a git repository as a project, and cut workspaces from it as git worktrees.

That is the whole thesis, and it is a better one than "an AI IDE". ThinkRail is a JetBrains incubator project, around 7,100 stars with 5,760 added in the past week, and it is built around pi, the open coding agent. What JetBrains added is not a chat panel. It is the plumbing that lets several agents work at once without stepping on each other.

Worktrees instead of hope

If you have run two agents on the same repository, you know the failure mode. One starts editing auth.ts, the other decides to refactor auth.ts, and you spend the afternoon doing archaeology on a merge conflict that both sides believe they wrote.

ThinkRail's answer is that every workspace is a git worktree with its own branch and its own working directory. Agents work in parallel and none of them touch your checkout. You merge the branch you like and delete the rest.

There is a nice piece of housekeeping on top: finished and dormant workspaces settle onto a per-project shelf on their own, when their pull request merges or closes, or after a quiet week, and come back the moment you work in them again. If you have ever had twenty stale branches named fix-thing-2, this is the feature you did not know you wanted.

The topbar tracks where the active branch stands against origin and its pull request, and puts the next step one click away: publish, push, or open a PR described from the plan, the commits, your template, or an agent-written draft. Once a PR is open it shows CI checks and the review decision, and lets you hand failing checks or a diverged branch back to the agent.

The IDE part is real, not decorative

Splittable Monaco tabs, a file tree with live git change marks, a changed-files view, terminals, and documents, all scoped to the active workspace. You can leave anchored review comments on files and diffs and send them into a chat as structured context. Or open the worktree in your installed IDE, which is the honest admission that some of us still want WebStorm.

Chats stream with a live token and cost readout per session, which is the kind of detail that only appears when the people building it are paying their own bills. You can steer a running turn, queue a follow-up, delegate to subagents, and work a shared plan the agent updates while you edit it. Each completed step can be committed and reviewed on its own, which is a much better unit of review than "here are 38 files".

The command palette at ⌘K, or a double tap of Shift, finds chats, workspaces and projects across every open project. With nothing typed it lists the chats waiting for you, which is the correct default for a tool that runs many sessions.

Specs as the thing that survives

The feature I keep coming back to is the spec graph. A connected set of SPEC.md files lives beside the code, and the agent reads, searches and maintains it through dedicated spec_* tools. The read-only Specs tool renders the graph as a tree in the workbench.

The reasoning is sound. Context windows end. Sessions end. What survives is what you wrote down. Most agent tools treat "remember the plan" as a memory problem; ThinkRail treats it as a documentation problem, which is the version that a human can also read six months later.

It is also the feature most likely to rot. A spec graph that the agent maintains and nobody reviews becomes a very confident, very detailed description of software that no longer exists. The tooling makes maintenance cheap; it does not make it free, and the discipline is on you.

Install

Two forms, both additive: a native desktop installer, and a self-contained CLI that opens the same app in your browser. Both publish SHA256SUMS on the releases page.

Command line on macOS or Linux, and on Windows under Git Bash:

curl -fsSL https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.sh | bash

Windows, from cmd or PowerShell:

powershell -c "irm https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.ps1 | iex"

Then:

thinkrail ~/code/my-repo

You need git on your PATH and a model provider. Sign in with JetBrains AI from the app, or connect any provider through pi's own auth. There are no ThinkRail accounts, which is a sentence I did not expect from JetBrains.

Desktop builds on Linux need glibc 2.38 or newer with GTK 3, WebKitGTK 4.1, Ayatana AppIndicator 3 and librsvg 2 — Ubuntu 24.04 or later, in practice. The updater only appears when the package carries a valid HTTPS feed identity, so installations older than that identity need one manual install first.

The detail that makes it portable

ThinkRail reads your existing ~/.pi/agent configuration. Point it elsewhere with PI_CODING_AGENT_DIR if you keep a work profile. Under Settings, Custom servers connects any OpenAI-compatible endpoint — LiteLLM, sglang, vLLM, Ollama, LM Studio, llama.cpp — and writes it into pi's models.json, so those models show up in the chat picker and in the CLI alike.

MCP servers from your mcp.json come along too, with the right behaviour: ThinkRail asks in the chat before calls the server does not mark read-only, keeps repository-defined servers off until you approve them, and signs you into OAuth servers from settings.

Agent extensions are equally pragmatic. Settings lists what the agent gets, lets you switch each one off, and installs any pi package by source — npm, git, or a local folder — for you or for a repository. The ask-user-question and visualize tools are published as separate packages, so a vanilla pi in a terminal gets the same multiple-choice prompts and inline diagrams.

What I would watch

Seventy-six hundred stars in a week for an incubator project is a lot of attention for something that has not been through a JetBrains release cycle. Incubator projects at JetBrains have a history of either becoming products or quietly stopping, and betas have a way of becoming the version you depend on.

The other risk is conceptual. This is a very complete tool with a lot of surfaces: worktrees, specs, palettes, extensions, MCP, themes, fonts, four built-in languages with a documented path to add your own. Every one of those is a place to configure instead of write code. The best outcome for ThinkRail is that the worktree model becomes so obviously correct that nobody talks about it anymore, and the rest of the app gets out of the way.

Try it if you already run parallel agents and your current answer is "multiple terminal windows and crossed fingers". The worktree isolation alone is worth the download. Try it as a normal IDE and you will find it is not trying to be one.