JetBrains ThinkRail Gives Every Coding Agent Its Own Copy of Your Repo. That's the Point.

A plain-language look at the new open-source agent IDE, why one-branch-per-agent matters, and how to try it without risking your main checkout

Running one coding agent is easy now. Running three at once in the same folder is where things get strange, and a new JetBrains project bets the fix is giving each agent its own copy of the repo.

One agent is halfway through renaming a function. Another runs the tests and sees a broken build that is not its fault. A third "fixes" the half-finished rename. Meanwhile you edit a file by hand and lose your change when an agent rewrites it. Nobody did anything wrong. They were all standing in the same room.

JetBrains' new open-source project, ThinkRail, is built around that exact problem. Its own requirements doc states it in three words: "Parallel agents collide." The answer it ships is simple to describe. Every agent workspace gets its own copy of the repo on its own branch, and your main branch stays untouched until you merge.

That is the idea worth taking away even if you never install it: for parallel agents, isolation should be the default and sharing should be the exception you choose. Most tools today work the other way around.

What ThinkRail is

ThinkRail is an agentic IDE: a lightweight, web-based code editor where the main way you write code is by chatting with agents. It sat at #11 on the Trendshift momentum board when I read it around 15:15 ET on October 27, with about 3.8k GitHub stars that afternoon, and it carries a JetBrains incubator badge. That last part matters. This is an early project, not a new IntelliJ.

The agent inside it is pi, a minimal terminal coding agent from Earendil, MIT licensed, that works with more than 15 model providers including Anthropic, OpenAI, Google and Mistral. ThinkRail runs pi inside the app and wraps it in an interface with an editor (Monaco, the same editor component VS Code uses), a file tree that marks git changes, terminals and review comments you can anchor to lines.

You sign in with JetBrains AI or connect any provider through pi's own login. ThinkRail has no accounts of its own; its state lives in ~/.thinkrail and pi's settings stay in ~/.pi/agent, according to the README. The code is Apache-2.0.

The idea: one branch per agent

The mechanism underneath is a git feature many developers have never touched: the worktree.

Normally a git repository has one working folder, the files you see and edit. A worktree is a second (or third, or tenth) working folder attached to the same repository, each checked out on its own branch. They share history, so they are cheap to create. But edits in one folder do not show up in another until you merge.

Picture a shared kitchen versus a row of separate prep stations. In the shared kitchen, three cooks reach for the same cutting board. With prep stations, each cook has a board, and the plates only come together at the pass.

ThinkRail's requirements doc says each workspace it creates "is a git worktree with its own branch and cwd" (its own working directory). Agents run in parallel in their own workspaces while the main branch stays clean "until the user merges." Working directly in your project folder, which ThinkRail calls the Default workspace, is allowed, but the doc is firm that it is "an explicit choice, never the default."

That one design choice removes most of the collisions above. The renaming agent cannot break the testing agent's build, because they are not looking at the same files. Your hand edits stay yours.

Inside a workspace you can run several pi chats at once, each with its own model, and spin up subagents as isolated child sessions in the foreground, in parallel or in the background.

When a workspace is ready, ThinkRail pushes its branch and opens or updates a GitHub pull request through your gh command-line tool. If gh is not available, it falls back to a prefilled compare link (or GitLab's new merge request page). The merge stays a human step.

Two smaller details show the same thinking. If you already use worktrees by hand, ThinkRail can attach an existing one in place instead of making a new copy. And when an agent works through a multi-step plan, the requirements doc says each step can be committed on its own when its changes are provably that step's, with an independent reviewer able to check them. Small, separate commits are much easier to review than one giant "agent did stuff" commit, and much easier to roll back.

ThinkRail also bundles workflows for the jobs that surround the code: setting up a project, brainstorming a design, shipping a pull request. They are written as portable Agent Skills, the same folder-of-instructions format Claude Code and other agents read, so the ones you write are not locked to this IDE.

The second idea: a spec that outlives the chat

Isolation solves the "same room" problem. It does not solve the "nobody remembers why" problem.

Every agent chat ends. Whatever you agreed on in it ("keep the API backwards compatible," "don't touch the billing module") disappears with the session. ThinkRail's requirements doc names this directly: decisions made in chat otherwise "end with the session."

Its fix is a spec graph: a set of SPEC.md files kept beside the code, describing what each part is supposed to do. The agent searches, reads and maintains them through dedicated spec_* tools, and the UI shows the graph as a read-only tree. The next agent, in the next workspace, starts from the written intent instead of from zero.

This is the same instinct behind AGENTS.md and CLAUDE.md files, pushed down to the module level. ThinkRail's own repo keeps a top-level AGENTS.md, and the nightly.7 release notes say the team removed its CLAUDE.md and made AGENTS.md canonical, which tells you they work this way too.

The honest caveat: a spec is only as good as its upkeep. An agent that "maintains" a spec can also drift it. Read the spec diffs in your pull requests the same way you read the code diffs.

Put this into practice

Try it on a side project first. Here is the lowest-friction path, straight from the README.

Check the requirements. You need git on your PATH and a model provider. macOS 14 or later works on Apple Silicon or Intel. Windows x64 is supported. On Linux, the desktop build needs glibc 2.38 or newer (the system C library version), which in practice means Ubuntu 24.04 or newer, plus a few GTK and WebKit libraries the README lists.

Install the CLI (macOS, Linux, or Git Bash on Windows):

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

On Windows PowerShell:

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

The script installs the stable channel by default; end the command with | bash -s -- --channel nightly instead of | bash if you want the newest builds. If you would rather not pipe a script into your shell, download the thinkrail-desktop-* build for your platform from the releases page and check it against the SHA256SUMS file each release includes.

Open a repo:

thinkrail ~/code/my-side-project

Then run the experiment that shows the point. Create two workspaces. Give one agent a refactor and the other a bug fix in a different part of the code. Let both run at once. You should see two branches, two separate folders, and a main branch that has not changed. Open a PR from one, merge it, and watch the other keep going untouched.

If you use MCP servers (the plug-ins that give agents extra tools), ThinkRail reads them from pi's mcp.json and asks for approval before using any server not marked read-only. Keep that prompt on.

To remove it later, thinkrail uninstall asks whether to delete ~/.thinkrail; --remove-data deletes it and -y skips the prompts.

Honest limitations

It is early. The newest tags on the releases feed when I checked on October 27 were nightlies, the latest being v0.3.0-nightly.7 from that day. The README's own example of pinning a stable channel uses version 0.1.2. Expect breaking changes.

Basic telemetry is always on. The README says ThinkRail sends basic usage events and error reports tied to a random installation ID, and that usage analytics "never include prompts, code, files, credentials, or account identity." The --no-analytics flag (or THINKRAIL_NO_ANALYTICS=1) only turns off the optional "Share additional usage data" setting for a run. It does not stop the basic events. If your company forbids any outbound telemetry from dev tools, that is a blocker.

Signing is uneven. The macOS CLI is signed but not yet notarized, Linux artifacts are unsigned, and the README warns that some macOS disk images may be blocked by Gatekeeper.

Worktrees are not free. Each workspace is a full checkout on disk. Dependency folders like node_modules get installed per workspace, so ten agents can mean ten copies. Plan disk space accordingly.

Isolation is not security. A worktree keeps agents from stepping on each other's files. It is not a sandbox. An agent in a worktree can still run shell commands, reach the network and use whatever credentials your machine has. ThinkRail's isolation is about collisions, not containment.

You are adopting two projects, plus a model bill. ThinkRail's agent is pi, so pi's behavior, defaults and update pace come along for the ride. And the code being free says nothing about the models: cost, limits and data handling depend on whichever provider you connect.

Should you switch?

Probably not your main editor, not this month. ThinkRail is an incubator project on a nightly track.

But the pattern is worth stealing today, with or without it. If you run more than one agent on a repo, give each its own worktree and branch:

git worktree add ../myrepo-fix-auth -b agent/fix-auth

Then point the second agent at that folder. You get most of the collision protection with a tool you already have. And if you find yourself repeating the same instructions to every new chat, write them into a spec file beside the code.

ThinkRail's real contribution is making both of those the default instead of a habit you have to remember. Try it on a side repo, run two agents at once, and see whether your main branch stays as quiet as it promises.

Sources: ThinkRail README and goal-and-requirements.md pinned to tag v0.3.0-nightly.7, reviewed October 27, 2026 · ThinkRail releases · pi · Trendshift (momentum ranking, read about 15:15 ET Oct 27) · star count from shields.io, Oct 27.