JetBrains ThinkRail: An Agentic IDE Built Around the pi Coding Agent
JetBrains has published ThinkRail, an open-source "agentic IDE" that wraps the pi coding agent in a rich workbench and isolates each task in its own git worktree. It matters because it is a JetBrains-branded IDE that does not use JetBrains' own editor engine: the UI is Monaco, the runtime is Bun, and the agent is a third-party npm package rather than a JetBrains-built model stack.
The project lives at github.com/JetBrains/thinkrail and is licensed under Apache 2.0. The repository carries a "JetBrains incubator project" badge, and the README describes ThinkRail as "the agentic IDE that gets better every time you use it — learning your project through living specs today, and building its own capabilities tomorrow." The project has its own site at thinkrail.ai and a blog at thinkrail.ai/blog.
What ThinkRail actually is
ThinkRail is a thin host that runs the pi coding agent in-process and bridges it to a web UI. The README states the division of responsibility explicitly: "pi owns models, skills, compaction, cost, and session state; the app owns the workspace, the editor, and the wire — it never assembles prompts behind your back."
The agent is the npm package @earendil-works/pi-coding-agent. ThinkRail adds the workspace model, the editor, the chat surface, and the protocol between them. The stated roadmap is "full extension support, so ThinkRail can create the tools it needs based on how you actually work."
Isolated workspaces are the core abstraction
ThinkRail's central design decision is that every agent task runs in a separate git worktree rather than in your working checkout. You open any git repo as a project and cut workspaces from it as git worktrees, each with its own branch and working directory, so agents can work in parallel without touching your checkout. You can also attach existing worktrees or explicitly work in the project folder itself.
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." The topbar shows where the active branch stands against origin and its pull request, with publish, push, or open-a-PR actions one click away. PR descriptions can be drafted from the plan, the commits, your PR template, or an agent-written draft. Once a GitHub PR is open, ThinkRail shows CI checks and the review decision, and lets you mark it ready, hand failing checks or a diverged branch to the agent, merge it with the repository's last-used method, reopen it, or delete the remote branch.
The editor is Monaco, not a JetBrains engine
ThinkRail's workbench is a splittable layout of Monaco editor tabs, a Files tree with live git change marks and a Changed view, terminals, and documents, all scoped to the active workspace. You can leave anchored review comments on files and diffs and send them to a chat as structured context, or open the worktree in your installed IDE.
This is the detail that drew the most criticism on Hacker News. Commenter @theptip wrote:
Hmm, most of this seems like it would be cutting edge in 2025. And why do I want to use Monaco? If I'm in the JetBrains ecosystem isn't it because I prefer their IDEs over VSCode? The versioned and linked spec feature sounds somewhat interesting though.
Commenter @tiku put it more bluntly: "Jetbrains using vs code is really sad." Another commenter, @TehCorwiz, noted the same thing and said they preferred JetBrains' own engine: "So this looks like it's based on VSCode instead of their typical engine. I have complex feelings about that. I actually like their engine."
Chats, plans, and specs
ThinkRail supports several concurrent pi sessions per workspace, each with its own model and a live token and cost readout. You can steer a running turn or queue a follow-up, delegate to subagents, and work a shared plan that the agent updates and you edit; each completed step can be committed and reviewed on its own.
The project's answer to context loss between sessions is "living specs": a connected graph of SPEC.md files that lives beside the code. The agent reads, searches, and maintains that graph through dedicated spec_* tools, and a read-only Specs tool renders it as a tree in the workbench. ThinkRail is developed spec-first itself — a SPEC.md sits beside every module, and a change that moves a boundary, contract, or decision updates the spec in the same change. The canonical product and design specs are goal-and-requirements.md and architecture.md.
One commenter, @photios, asked where to learn more about the SPEC.md format and workflow, then found the answer at thinkrail.ai/blog/thinkrail-sdd/.
Skills, MCP servers, and agent tools
Portable Agent Skills that you already keep for other coding agents are read in place. Bundled workflows guide project setup, design brainstorming, and shipping a pull request — pushing the workspace branch and opening or updating its GitHub PR through your own gh.
Beyond the shell, the agent gets web research and inline rendering of diagrams, option comparisons, and file previews directly in the chat. When the agent proposes a UI change, it shows a before/after mockup you can comment on like a diff. Settings → Extensions lists the ThinkRail extensions the agent receives and lets you switch each one off.
MCP servers come from your pi mcp.json or can be added from Settings, including a few presets. ThinkRail asks in the chat before calls the server does not mark read-only (or always allows tools you trust in a project), keeps servers a repository defines off until you approve them, signs you in to OAuth servers from Settings, and shows each chat's servers next to its background commands and subagents.
Providers and credentials
ThinkRail has no accounts of its own. You sign in with JetBrains AI or connect any provider through pi's own auth. Commenter @lousken questioned the scope of that support: "Where is local model support and just any openai compatible api support? Pi agent is compatible with more stuff."
Install: desktop app and CLI
ThinkRail ships in two additive forms — a native desktop installer and a self-contained thinkrail CLI — both published with SHA256SUMS on the releases page.
Desktop builds are available for macOS Apple Silicon (DMG; there is no Intel desktop build), Windows x64 (extract the complete setup ZIP and run its setup executable in place), and Linux x64/ARM64 (extract the setup tarball and run installer). Linux desktop builds need glibc 2.38+ with GTK 3, WebKitGTK 4.1, Ayatana AppIndicator 3, and librsvg 2, meaning Ubuntu 24.04 or newer, with the packages libgtk-3-0 libwebkit2gtk-4.1-0 libayatana-appindicator3-1 librsvg2-2.
The CLI installer downloads the right binary, verifies its SHA-256 checksum, and puts thinkrail on your PATH. On macOS, Linux, and Windows under Git Bash:
curl -fsSL https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.sh | bash
On Windows from cmd and PowerShell:
powershell -c "irm https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.ps1 | iex"
Then run thinkrail, optionally with a git repo to open as a project: thinkrail ~/code/my-repo. The CLI needs git on your PATH and a model provider — either a JetBrains AI sign-in from the app or your own provider credentials. thinkrail --help lists flags and thinkrail --version prints the build.
The installer accepts --channel stable|nightly and --version, and a pinned version must belong to the selected channel. On Windows those options are environment variables: THINKRAIL_CHANNEL, THINKRAIL_VERSION, THINKRAIL_PREFIX, and THINKRAIL_NO_MODIFY_PATH. thinkrail update re-runs the installer for the installed channel and replaces <prefix>/bin/thinkrail[.exe]. thinkrail uninstall removes the executable, the PATH entry the installer added, and the install metadata, and asks whether to delete your ~/.thinkrail app state — kept by default, with --remove-data to delete it and -y to skip the questions.
Packaged stable and nightly desktop builds check for updates in the background and offer them in Settings → Updates, following a Download → Preparing update → Install & Restart flow. Nothing is applied until you choose Install & Restart. The updater appears only when the package carries a valid HTTPS feed identity; installations that predate that identity need one manual installation first.
Platform and signing notes
JetBrains signs the Windows CLI, the desktop setup executable, and every executable and DLL the desktop app installs. The macOS CLI is signed but not yet notarized. Signed and notarized desktop DMGs require a coordinated JetBrains service pipeline, so older published DMGs and locally built packages may still be unsigned and blocked by Gatekeeper. Linux artifacts are unsigned. There is no prebuilt macOS Intel CLI — it must be built from source.
Architecture: three rings
ThinkRail is organized into three layers:
- Engine host —
packages/server(pluspackages/shared): aBun.serveHTTP+WS host with one in-processpisession per chat, launched byapps/cliorapps/desktop. - The wire —
packages/contracts: the typed, versioned protocol between host and UI. - UI client —
apps/web: React 19 + Zustand + Tailwind v4, shipped independently; it dials a host over the wire and depends on the contracts only.
Both the desktop app and the browser CLI embed the same engine host, and app state lives under ~/.thinkrail. Building from source requires Bun 1.4.4 (the pinned package manager and runtime), Node.js ≥ 22.19 (required by the in-process pi engine), and an authenticated pi provider for agent work. The README's development commands are bun install, bun run dev for host and web client together, bun run build:binary for a standalone CLI artifact, and bun run desktop:dev / bun run desktop:build for the Electrobun app.
The Bun dependency drew a reaction from @photios: "Also... why bun?! I just finished purging it from all my systems, ha! It'd be cool to have plain pnpm support."
Localization
Settings → Language follows your system language or a language you pick. English and Simplified Chinese are built in. You can add a language ThinkRail does not ship yet by dropping a translated en.json into ~/.thinkrail/locales, and it applies as you save. Agent replies and tool output stay as the agent wrote them.
Analytics and privacy
ThinkRail collects basic usage events — launches, chat creation, message sends, provider connections — tied to a random installation ID. Usage analytics never include prompts, code, files, credentials, or account identity. Error reports are always sent, tied to the same installation ID, and contain the error type and code plus where in ThinkRail's own code it happened; they never include error messages, file paths, names, URLs, or anything from your projects or extensions.
Additional product usage data and how you found ThinkRail are shared only while "Share additional usage data" is on; the switch is offered at first launch and lives in Settings → Privacy. Running thinkrail --no-analytics (or setting THINKRAIL_NO_ANALYTICS=1) turns additional sharing off for that run. With additional sharing on, a packaged build may open the ThinkRail blog in your browser once to link your installation to the website visit that brought you there — only where you accepted marketing cookies on the website or no consent is required — and that link expires after 30 days.
What Hacker News commenters pushed back on
The discussion was largely skeptical, and several distinct criticisms recurred.
The README itself was questioned. Commenter @exizt88 wrote: "I refuse to take a repo with an AI-generated readme seriously. If you haven't bothered to write a readme, what else have you not bothered to do? (100% AI according to Pangram btw)"
Overlap with JetBrains' other AI IDE efforts. @Deukhoofd asked: "Didn't JetBrains release JetBrains Air recently? This looks like it's basically the same basic premise, except implemented differently. What's their strategy here, are they just launching competing products?" @rcr-anti, a long-time JetBrains full-product-pack subscriber, said they wanted "either a convergence of all their IDEs via plugins or a lighter universal editor like Fleet was getting close to," and added that they "thought they were going that way with Air, until they killed it yet again. Air is a plugin now, but that's back to the specific IDE thing."
The worktree-plus-agent pattern is not novel. @sigotirandolas argued: "I don't see the point of those new-IDEs. They are mostly just worktrees+sandbox+tabs+prompts, which is just git+docker+tmux+thinking, but if you actually learn to use those tools instead of handcuffing your agents to whatever take the IDE has, you're going to be much happier and effective. (That's also why there are so many of them: It just isn't that hard, everyone feels like a genius when they figure it out, and it's a great way to resume-build in the AI era)."
Isolation is insufficient. @collimarco wrote: "Running agents outside containers seems crazy to me... It should at least launch a sperate microVM or container for each agent / task."
Enterprise billing friction. @hkchad said: "The problem with all the AI IDE's is you can't use them with most enterprise/teams accounts, you have to use API which can cost upto to 10x more over an enterprise plan. I really like JetBrains, used them for a LONG time, but just find myself doing 99% of my day to day with iterm and sublime now."
Worktrees versus other version-control workflows. @VMG observed: "It feels like the day after I got comfortable with jj everybody become obsessed with git worktrees."
Incumbent loyalty, with caveats. @dr_faustus, who has used JetBrains IDEs for over a decade, said they "rarely open them anymore because working on several worktrees concurrently is extremely frustrating and wasteful," and criticized the company's AI strategy as "all over the place" with "opaque and overpriced tokens." @throwaw12 said it "feels like JetBrains is dying, and they're trying very hard to survive," while @johnhamlin wrote simply, "Still rooting for these guys," and @jwpapi said they were "willing to give it a try."
Competing tools were named. @aliasxneo said they would "have to be strongly convinced to leave oh-my-pi and Paseo." @dangoodmanUT framed the release as overdue: "It's nice to see JetBrains finally wake up and realize they can't sell a Cursor competitor from 2024 anymore. Something about JetBrains writing a new IDE seems bold... not sure if it feels correct."
Contributing and license
Contributions are governed by the repository's CONTRIBUTING.md, which covers the checks, end-to-end suites, desktop packaging, and repository layout, and by a Code of Conduct. ThinkRail is licensed under the Apache License 2.0.