Research review / opensource

JetBrains ThinkRail: An Apache-2.0 Incubator IDE That Gives Each Coding-Agent Task Its Own Git Worktree and Keeps a Graph of SPEC.md Files Beside the Code

ThinkRail, a JetBrains incubator project built around the open pi coding agent, shipped nightly 0.3.0-nightly.6 on October 25 and was on the Hacker News front page when this digest checked it. Its two ideas worth borrowing are isolated worktree workspaces for parallel agents and specs the agent maintains as files.

By Sandeep Belgavi · Published 2026-10-26

ThinkRail is a desktop IDE from JetBrains, labelled a "JetBrains incubator project" in its README. The repository was created on July 8, 2026, is licensed Apache-2.0, and had about 1,700 stars when this digest checked it; a single star count says nothing about quality or growth. The dated event is release v0.3.0-nightly.6, published on October 25, 2026 at 06:49 UTC with 35 merged pull requests, and the project was on the Hacker News front page when this digest looked on October 26. Every release so far is a nightly prerelease, so treat it as early software.

What it is

ThinkRail runs the open pi coding agent in-process and serves a React web UI around it, either as a native app or through a thinkrail CLI that opens the app in a browser. pi handles models, skills, compaction, cost and session state. ThinkRail handles the workspace, editor, terminals and diffs. Models come from JetBrains AI or any provider configured in pi, and the README says "ThinkRail has no accounts of its own."

Worktrees as the unit of agent work

A project is a git repository, and each workspace is a git worktree on its own branch and directory. Several agent chats can run in parallel, each in its own workspace. You merge the branch you want and delete the others, and dormant workspaces move to a per-project shelf. This is a clean answer to a practical problem with parallel coding agents: two agents editing the same checkout overwrite each other, while two worktrees fail only at merge time, where a human is already looking.

Specs as files the agent maintains

The README describes "A connected graph of SPEC.md files" that lives beside the code. The agent reads, searches and updates it through dedicated spec_* tools, so intent survives across sessions, and the workbench shows the graph as a read-only tree. ThinkRail also reads existing Agent Skills in place and ships bundled workflows for project setup, design brainstorming and opening a pull request.

Trust defaults worth noting

Two MCP defaults are relevant to this week's instruction-file attacks. According to the README, ThinkRail asks in the chat before calls to servers that are not marked read-only, unless a project trusts those tools, and it keeps servers a repository defines switched off until the user approves them. Its README also says "Usage analytics never include prompts, code, files, credentials, or account identity", while error reports are always sent, with error messages, file paths and project names excluded; a settings switch and a --no-analytics flag control extra sharing. The October 25 nightly also bumps Bun to 1.4.4 "to drop the compromised emSign roots", the eMudhra certificates this digest covered on October 23.

An original teaching example

Suppose you want two candidate designs for a rate limiter: a token bucket and a sliding window. Write a short SPEC.md for the limiter that states the contract, for example the allowed burst, the behaviour at the boundary and what a rejected request returns. Then open two workspaces from the same commit and give each agent one design. Because each runs in its own worktree, the same test file can be run in both without interference, and the spec is the shared yardstick. Keep the spec change in a separate commit so you can see whether an agent edited the contract to make its design pass. That last check is the main reason to keep specs as files: an agent that rewrites the requirement leaves a diff. This workflow is a proposal; it was not run for this article.

What remains uncertain. There is no stable release, no published evaluation, and Linux artifacts are unsigned according to the README. Whether the spec graph helps on large codebases is untested here.

Analysis: The transferable ideas do not require ThinkRail. Give each agent task its own worktree and branch, keep the requirement in a versioned file the agent can read but whose edits you review separately, and keep repository-defined tool servers off until a person approves them. Those three habits make parallel agents safer whichever IDE or harness runs them.

Sources and evidence

JetBrains' Apache-2.0 incubator IDE ThinkRail, built around the open pi coding agent, shipped v0.3.0-nightly.6 on October 25 with 35 merged pull requests, including a Bun bump to drop the compromised emSign roots. It runs each agent task in its own git worktree, keeps a SPEC.md graph the agent maintains through spec tools, and keeps repository-defined MCP servers off until approved. These are useful patterns, but there is no stable release yet.