JetBrains just open-sourced an agentic IDE — Apache 2.0, on GitHub as of yesterday — and the name of the repository matters less than the three ideas in it: agents that never touch your checkout, a project's truth that survives the session, and no accounts anywhere. It's called Thinkrail, it wraps the
picoding agent, and after an evening in the repo I think it's the clearest statement yet of what "IDE" means when the coder is a fleet.
This week the agent stack is assembling in public: NVIDIA shipped the runtime layer (OpenShell), and now JetBrains ships the environment layer. Here's what Thinkrail actually does, mechanism by mechanism.
Idea one: isolation by worktree, not by prompt
Every workspace in Thinkrail is a git worktree with its own branch. The README's sentence deserves to be quoted in full: "Agents work in parallel without touching your checkout."
That's the whole design, and it's the correct answer to a question most agent tools answer badly. The common pattern today is: agent edits files in place, you review the diff in the same tree you're building in, and a second agent is a merge conflict generator. Worktrees flip it: N agents, N branches, your checkout untouched, merges become the explicit coordination point. It's the same isolation insight as OpenShell's sandboxes, applied one level up — not "what can the agent touch" but "which tree does the agent live in."
Idea two: SPEC.md as ground truth
The deeper bet: agents are unreliable because their context dies with the chat. Thinkrail's answer is a graph of SPEC.md files sitting beside every module, which the agent itself maintains through dedicated spec_* tools — "so intent survives the session."
Read that again: the documentation is not a byproduct of the work; it's a maintained artifact the IDE treats as ground truth. The agent reads the spec to know what to do, does the work, then updates the spec to record what it learned. JetBrains dogfoods it — the repo is developed spec-first, a SPEC.md sits next to every module. Whether the graph stays honest under agent-driven rewrites is the open question (a spec the agent both follows and edits is one prompt injection away from redefining the project's truth), but as an architecture it's the first serious answer to "how does an agent remember my project" that isn't a vector database.
Idea three: no accounts
"ThinkRail has no accounts of its own" — you bring your own provider credentials, exactly like OpenShell's provider model. The IDE is a host: an HTTP+WS engine (Bun.serve, one in-process agent session per chat), a typed versioned wire protocol (packages/contracts), and a React 19 client. Skills, workflows, MCP servers, subagents, per-chat model selection with token/cost readouts. It's an IDE-shaped shell around an agent protocol, and the shell has no opinion about who pays for inference.
The honest margins
The tagline — "gets better every time you use it" — is marketing for what's actually shipped: living specs today, self-built capabilities tomorrow. It's brand-new (0.x, this week), the wire protocol is versioned but young, and "spec drift under agent edits" is a real attack on its own premise that no README answers yet. The desktop installers exist (macOS Apple Silicon, Windows, Linux), and the CLI is two commands — but nobody has a year of usage to point at.
Run it yourself
curl -fsSL https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.sh | bash
thinkrail ~/code/my-repo
# developers: Bun 1.4.4 + Node >= 22.19, then `bun install && bun run dev`
Repo: github.com/JetBrains/thinkrail · Apache 2.0 · built around the pi coding agent
TL;DR — worktrees for parallel agents, a self-maintaining spec graph for durable intent, your keys and no accounts. The week built the runtime (NVIDIA), the IDE (JetBrains), and left one layer conspicuously unfinished: who proves what the fleet actually did. That's the next post.
Top comments (0)