ThinkRail: JetBrains’ Open-Source Agentic IDE Built on Git Worktrees

ThinkRail (JetBrains/thinkrail) is one of the fastest-climbing repos on GitHub this week: an open-source agentic IDE that JetBrains InnovationHub built around pi, the minimal terminal coding agent. Its core idea: every workspace is its own git worktree, with its own branch, files, terminals and chats, so several agents can work on one repo without stepping on each other or on your checkout.

On 3 Nov 2026 I read the README, the architecture and workspace specs, both install scripts and the v0.3.0 and v0.3.1 release notes, and checked the numbers against the GitHub API and the trending page. I didn’t install it or run an agent: every command below is checked against the repo, and anything I couldn’t confirm stays out.

1. What It Is: Stars, License and Scope

ThinkRail calls itself “the agentic IDE that gets better every time you use it”. In practice it’s a workbench of Monaco editor tabs, a git-aware Files tree, terminals and chats, scoped to one workspace at a time, around an agent that does the work. The site credits JetBrains InnovationHub, and the README carries JetBrains’ incubator badge. It arrives as JetBrains’ own survey puts weekly agent use at 90% of developers.

⭐

GitHub stars

~7.3K

GitHub API, 3 Nov 2026, with ~435 forks; +4,812 this week

⚖️

License

Apache-2.0

ThinkRail itself. pi, the engine, is MIT

🏷️

Latest stable

v0.3.1

Published 1 Nov 2026. Nightlies are on 0.4.0

🧠

Engine

pi 1.5.0

Pinned in the root package catalog

Why it’s trending now

Created on 8 July 2026 and introduced on 19 Aug, it has shipped fast since: v0.2.0 on 18 Oct, v0.3.0 on 29 Oct and v0.3.1 on 1 Nov, plus near-daily nightlies. GitHub’s weekly trending page shows +4,812 stars this week, with max-sixty/worktrunk, a worktree CLI for parallel agents, on the same list.

Not JetBrains Air, and not a plugin

JetBrains already has Air, an agentic environment in public preview since March 2026 that runs Codex, Claude Agent, Gemini CLI and Junie over ACP. ThinkRail is a separate, pi-only project whose product spec lists “a second agent runtime” as a non-goal. Nor is it an IntelliJ plugin: it’s a standalone app that can hand a worktree to your IDE.

2. The Architecture in 4 Steps

The README sums it up as “a thin host that runs pi in-process and bridges it to a rich web UI”. Following architecture.md, a chat message passes through four layers.

🚀

1. Two launchers, one host

The desktop app wraps the host in Electrobun with a native system webview. The thinkrail CLI is a self-contained binary that boots the same host on localhost:24242 and opens your browser. Both embed one host library, and app state lives under ~/.thinkrail.

⚙️

2. An engine host with pi inside

packages/server is a Bun.serve HTTP and WebSocket host that runs one in-process pi session per chat. Every session gets bundled pi extensions (spec graph, workflows, todos, subagents, background commands) plus ThinkRail’s visualize, ask-user-question and web-access.

🔌

3. A typed, versioned wire

packages/contracts is the only coupling between host and UI. The React 19 client in apps/web depends on it, never on the server. It reads current state, then subscribes to deltas, so a reload, a second tab or a host restart rebuilds the same view, and a phone can dial a host over Tailscale.

🌳

4. Projects, workspaces, worktrees

A project is a git repo. A workspace is a git worktree on its own branch under ~/.thinkrail/worktrees/<project>/<branch>, owning its chats, files and terminals. Two exceptions stay yours and untouched: the Default workspace, which is the project folder itself, and existing worktrees you attach in place.

Who owns what: pi vs ThinkRail

pi owns models, skills, compaction, cost and session state. ThinkRail owns the workspace, the editor and the wire, and the README promises it “never assembles prompts behind your back”. In practice it reads your ~/.pi/agent config, so sign-ins, skills, packages and sessions are shared with the pi CLI, and a model server you add in ThinkRail lands in pi’s models.json.

What pi is, exactly

pi is the coding-agent CLI from the earendil-works/pi monorepo (badlogic/pi-mono redirects there): MIT, about 119.8K stars, npm @earendil-works/pi-coding-agent 1.5.0. npm lists Mario Zechner as author and Armin Ronacher among the maintainers. It calls itself “a minimal, extensible agent harness” and skips sub-agents and plan mode on purpose; ThinkRail adds both as pi packages. It needs Node.js 22.19+.

3. Quickstart: Desktop App or CLI

Two forms you can install side by side: a desktop app and the thinkrail CLI, both published with SHA256SUMS on the releases page. The commands come from the README, both install scripts and apps/cli/src/args.ts; I didn’t run them.

Option A: the desktop app

# Stable desktop builds (releases/latest points at the newest stable: v0.3.1 today)
# macOS 14+, Apple Silicon or Intel: open the DMG for your architecture
https://github.com/JetBrains/thinkrail/releases/latest/download/thinkrail-desktop-darwin-arm64.dmg
https://github.com/JetBrains/thinkrail/releases/latest/download/thinkrail-desktop-darwin-x64.dmg

# Windows x64: extract the ZIP, then run its setup executable in place, next to its payload
https://github.com/JetBrains/thinkrail/releases/latest/download/thinkrail-desktop-windows-x64.zip

# Linux x64 / ARM64: extract the tarball, then run ./installer
https://github.com/JetBrains/thinkrail/releases/latest/download/thinkrail-desktop-linux-x64.tar.gz
https://github.com/JetBrains/thinkrail/releases/latest/download/thinkrail-desktop-linux-arm64.tar.gz

# Linux desktop prerequisites: glibc 2.38+ with GTK 3 and WebKitGTK 4.1 (Ubuntu 24.04+)
sudo apt install libgtk-3-0 libwebkit2gtk-4.1-0 libayatana-appindicator3-1 librsvg2-2

Option B: the CLI (read the installer first)

# The README pipes the script straight into bash:
#   curl -fsSL https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.sh | bash
# macOS / Linux / Git Bash: download it, read it, then run it
curl -fsSL https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.sh -o install.sh
less install.sh
bash install.sh                        # stable channel, binary at ~/.local/bin/thinkrail
# bash install.sh --channel nightly    # nightly builds instead

# Windows PowerShell: a saved copy of install.ps1 takes parameters
irm https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.ps1 -OutFile install.ps1
notepad install.ps1
.\install.ps1                          # stable, binary at %USERPROFILE%\.local\bin\thinkrail.exe

Piping to bash is a trust decision

The script is careful: it resolves the release, checks the binary’s SHA-256 against SHA256SUMS and only then puts thinkrail on your PATH. But curl | bash runs whatever the server returns, unread. No script at all? Download a binary and SHA256SUMS, verify the checksum and save it as <prefix>/bin/thinkrail so self-update works.

First run and everyday commands

thinkrail ~/code/my-repo               # boot the host on localhost:24242, open the repo as a project
thinkrail --no-open --port 4000        # headless host, e.g. on a remote machine
PI_CODING_AGENT_DIR=$HOME/.pi/agent-personal thinkrail   # another pi config for this launch
thinkrail --version
thinkrail update                       # re-run the installer for your channel
thinkrail uninstall                    # keeps ~/.thinkrail unless you pass --remove-data

What the first launch asks of you

You need git on your PATH and a model provider. A short wizard asks the privacy question, then Connect a model. Existing Claude Code, Codex, Copilot, Kimi CLI or Grok Build sign-ins show up under Detected, but ThinkRail only reads their config files and never borrows credentials: you still sign in through pi. JetBrains AI connects through JetBrains’ central CLI, Settings → Providers takes any OpenAI-compatible server, and the PR features need gh signed in.

Platform notes

Desktop builds cover macOS 14+ (Apple Silicon and Intel), Windows x64 and Linux x64/ARM64; there’s no Windows on ARM build. JetBrains signs the Windows binaries; the macOS CLI is signed but not notarized, and Linux artifacts are unsigned. The Linux desktop app needs glibc 2.38+, which rules out Ubuntu 22.04.

Telemetry you can’t fully turn off

Per the README, the apps always send basic usage events (launches, chats, messages, provider connections) and error reports, tied to a random installation ID and free of prompts, code and credentials. Only additional usage data can be turned off: Settings → Privacy, --no-analytics or THINKRAIL_NO_ANALYTICS=1. Need zero outbound telemetry? That’s a blocker today.

4. The Parallel-Worktree Workflow, Step by Step

This is the part that earns the stars: the loop from idea to merged PR, as the README, the workspaces spec and the 0.3.0 post describe it.

🧭

1. Pick isolation on purpose

Opening a project lands on a Welcome fork: Start building cuts an isolated worktree and branch, while Work in project folder runs in your checkout with no isolation. ThinkRail never picks the folder for you, except for a brand-new empty repo’s setup chat.

✍️

2. Describe the task

In Create workspace you pick a base branch and describe the task; ThinkRail names the workspace and branch from that text, which also becomes the agent’s first prompt. The worktree is cut with --no-track, so a git push from its terminal never targets the base branch by accident.

🔀

3. Fan out

Repeat for the next task. Each workspace keeps its own chats, files, terminals and changes, and each chat is a separate pi session with its own model and live cost readout. Agents can also delegate to subagents, 4 at a time by default (1–16).

🔍

4. Review in place

The Files panel toggles between All and Changed. Anchor comments on files and diffs and send them to the chat as structured context, or have the agent work a shared plan whose steps can be committed and reviewed one by one. Open in hands the worktree to VS Code, Emacs, Vim or a JetBrains IDE on your PATH.

🚢

5. Ship from the topbar

The topbar always shows the branch’s next step: Publish, Push N or Sync (which previews its git pull --rebase and never force-pushes). Open PR pushes and opens or updates the PR through your own gh, drafting the body from the plan, commits or template. Then come CI checks, Fix with agent for failures, and Merge PR.

🧹

6. Merge the good one, delete the rest

Remove workspace deletes its chats, terminals and worktree but keeps the branch. Workspaces whose PR merged or closed, or that sat quiet for a week, settle onto a per-project shelf until you work in them again.

What a workspace is, in plain git (illustration, not ThinkRail commands)

# Roughly what "Create workspace" runs (packages/server/src/workspaces/SPEC.md)
git worktree add --no-track -b fix-login-redirect \
  ~/.thinkrail/worktrees/my-app/fix-login-redirect origin/main

# What "Open existing worktree..." parses to list checkouts you can attach
git worktree list --porcelain -z

# What "Remove workspace" runs: the folder goes, the branch stays
git worktree remove --force ~/.thinkrail/worktrees/my-app/fix-login-redirect
git branch --list fix-login-redirect   # still there

Nothing exotic, which is good news: your branches and history stay plain git, inspectable from any terminal. Note the --force: removing a workspace throws away anything uncommitted in it, so commit or push first.

A fresh worktree is a fresh checkout

git worktree add checks out tracked files only, so node_modules, .env files and build caches aren’t in a new workspace, and I found no setup hook for them in ThinkRail’s workspace spec. Plan an install step per workspace (or ask the agent to run it) and watch your disk space. Git also won’t check out one branch in two worktrees, hence a new branch per workspace.

A worktree isn’t a sandbox

Isolation here covers your checkout, not your machine. pi’s README says it has no built-in permission system for files, processes, network or credentials. ThinkRail gates what a repo can inject (its .pi resources, skills and MCP servers load only after you trust the project) and asks before MCP calls not marked read-only, but the shell tool still runs as you. For untrusted code, use a container, as pi’s docs suggest.

5. ThinkRail vs Plain Worktrees vs a Full JetBrains IDE

Worktrees for parallel agents aren’t new, and you can get them three other ways. The difference is how much of the loop around the agent each option owns.

How they compare

Aspect	ThinkRail	Worktrunk + your agent CLI	IntelliJ IDEA 2026.1+	JetBrains Air
What it is	An agentic IDE around one engine	A CLI that makes worktrees as easy as branches	A full IDE with agents in AI chat	An agentic environment for several agents
Agents	pi only, with any model pi supports	Whatever CLI you launch: wt switch -c -x claude feat	Junie, Claude Agent, Codex and ACP agents	Codex, Claude Agent, Gemini CLI, Junie (ACP)
Worktrees	Every workspace is one, created and removed for you	The core feature: switch, list, merge, remove	First-class worktree support since 2026.1	Worktrees or Docker containers, per task
Review and PRs	Diff, anchored comments, per-step commits, PR and CI in the topbar	wt merge squashes, rebases and cleans up; CI status in wt list --full	The IDE’s full VCS and diff tooling	Review in codebase context, then bring changes back
Editor depth	Monaco tabs; hands off to your IDE	Whatever editor you already use	Refactoring, debugger, inspections	Built-in terminal, Git client and preview; your IDE for the rest
Platforms	macOS 14+, Windows x64, Linux with glibc 2.38+, or a browser	macOS, Linux and Windows (winget)	macOS, Windows, Linux	macOS at launch; Windows and Linux announced
License and cost	Apache-2.0, no paid tier; you pay your model provider	MIT OR Apache-2.0, free	JetBrains license; agents via JetBrains AI or each agent’s account	Free download; JetBrains AI plan or your own keys

The worktrunk way, for comparison (from its README)

# Install (macOS / Linux) and enable directory switching
brew install worktrunk && wt config shell install

wt switch -c -x claude feat    # new worktree + branch "feat", start Claude Code in it
wt list                        # every worktree with its status
wt step copy-ignored           # copy gitignored files (node_modules, .env...) between worktrees
wt merge                       # squash, rebase onto the default branch, remove worktree + branch

How I’d choose

Happy in a terminal with Claude Code or Codex? worktrunk adds worktree hygiene without switching agents. Need refactoring and a debugger next to the agent? IntelliJ 2026.1+ has worktrees and several agents in the IDE. Want one window for the whole loop, from task to merged PR, with pi as the engine? That’s ThinkRail’s niche. And they mix: ThinkRail’s Open existing worktree… attaches a checkout made by worktrunk or plain git, untouched.

6. Use Cases: Where It Earns Its Place

These four are where the worktree-per-agent model changes the outcome, not just the UI.

🐛

Three fixes, three branches

Cut one workspace per bug from the same base, let each agent run and review each diff alone. Merge the right one, remove the rest; your checkout never saw any of it.

Best for: bug backlogs, flaky tests and small refactors you want done in parallel

⚖️

Competing approaches

Give the same task to two workspaces with different models (each chat picks its own) and compare the results side by side, cost readouts included.

Best for: model bake-offs on your own code instead of on benchmarks

📐

Spec-first projects

Set up project runs a skill that drafts a SPEC.md graph from the project’s goal before any code. The agent maintains it through spec_* tools, so decisions outlive the chat that made them.

Best for: long-lived repos where the agent keeps re-deriving decisions

🏠

A GUI for your pi setup or local models

It reads ~/.pi/agent, your pi packages, skills and mcp.json, so there’s nothing to migrate. Add an Ollama, vLLM or LM Studio server in Settings and its models appear in the chat picker and the pi CLI alike.

Best for: pi users, and teams that run models in-house (chat-completions API only for now)

What parallel agents actually cost

ThinkRail has no paid tier and no accounts; I found no pricing page. You pay the provider you connect, so four busy workspaces are four bills at once, plus subagents. The chat toolbar shows pi’s cost readout, subagents included since 0.3.0. One trap: v0.3.1 warns that a Claude Pro or Max sign-in is billed as extra usage per token, outside your plan limits, because pi connects directly via the API.

7. When NOT to Use It

This is the part a weekly star count won’t tell you.

✅ A good fit if...

• You already use pi, or want a model-agnostic agent with your own keys, JetBrains AI or local models
• You run two to four agent tasks on the same repo and keep losing track of branches and terminals
• You review agent changes line by line and want your comments to flow back to the agent
• You ship through GitHub PRs and already have gh signed in

⚠️ Skip it (or keep it experimental) if...

• You need a settled tool: it’s 0.x, with three stable releases in two weeks and 351 open issues and PRs
• You want Claude Code, Codex or Gemini CLI as the agent: ThinkRail is pi-only by design
• You need a sandbox: worktrees isolate files, not processes, network or credentials
• You’re on Ubuntu 22.04 or older or Windows on ARM, or need notarized or signed binaries everywhere
• You need zero outbound telemetry: basic usage events and error reports are always on
• It’s one agent on one small repo: a single session in your checkout is simpler
• You need refactoring, a debugger and deep language tooling: that’s still your IDE’s job

My take

Try the desktop app on a repo you know, keep the agent in workspaces, not the project folder, and give two of them small, independent tasks from the same base. Judge it on the review and PR loop, not the chat; if that loop saves you context switches, it’s worth the 0.x churn. Before scaling up, set a provider spending limit, commit before removing a workspace and containerize anything you don’t trust.

Conclusion

ThinkRail’s pitch holds up in the repo: pi does the agent work, ThinkRail owns the workspace, the editor and the wire, and every workspace is a plain git worktree. The loop around the agent, from task to review to merged PR, is where it beats a bare worktree CLI.

The costs are typical of 0.x: fast-moving releases, pi as the only engine, always-on basic telemetry, no sandbox, and parallel agents that multiply your model bill. Start small, keep work in isolated workspaces and let the PR flow earn your main branch’s trust.

Verification stamp

Repo stats and releases come from the GitHub REST API, and the weekly star delta from github.com/trending, both on 3 Nov 2026. Commands, flags, ports and paths come from the README, both install scripts, apps/cli/src/args.ts, architecture.md and the workspaces spec at commit c10f880 (v0.3.1). pi, worktrunk, Air and IntelliJ facts come from their own READMEs, docs and announcements. I didn’t install ThinkRail or run an agent.