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 (6)
The worktree-per-agent part makes total sense, but I think the SPEC.md graph is the bigger bet, and you named the catch well: if the agent both follows the spec and edits it, the spec can drift without anyone noticing. Did you see anything in the repo that makes spec edits go through review on their own, kept apart from code changes? Without that, I'd expect someone's SPEC.md to slowly turn into whatever the agent did last Tuesday.
Checked the repo, since it's open. The review separation you're asking about doesn't exist — one
CODEOWNERSgate for everything (*, five owners,require_code_owner_reviewon the main ruleset), so a spec edit rides the same review as the code it changed. What does exist is a mechanical drift check one layer down:check:spec-surfacecompares every enrolledSPEC.md's declared public surface against the module's TypeScript barrel and fails on "Spec surface drift" — which fences the cheap layer in both directions: code that changes the barrel without the spec update fails, and a spec declaring exports that aren't there fails too. What the agent can still do is update both to match whatever it did — the names check out because they were made to.Your "last Tuesday" drift lives in the layer the check can't see: the spec's narrative — invariants, trade-offs, decisions. That layer has exactly one fence today (the owner gate), and in a mixed PR one review does both jobs at once. The two fences that would actually separate them, cheapest first: a path-scoped
CODEOWNERSrow (**/SPEC.mdowned by a different or additional set — any PR touching spec and code then needs both sign-offs, and a spec-only change gets the spec review alone), and past that, the treatment this series runs on documents the agent follows and writes: the spec sealed at provision, edits arriving as named diffs against the sealed baseline. A spec the agent maintains is a governance file with a compiler attached — the compiler keeps the surface honest, and the seal is what keeps the story honest.For me the worktree idea is almost too obvious in hindsight — I've lost more time to an agent quietly editing the tree I was building in than to any single bad suggestion. Making merges the explicit coordination point feels right, but it also moves the pain somewhere else: what happens when two agents' worktrees touch the same module and both look reasonable? That's the part I'd want to see in practice before I trust a fleet of them, even with SPEC.md sitting beside every module.
The honest answer is that the merge stays hard — the isolation just changes what kind of hard. Two worktrees that each pass their own tests and both "look reasonable" produce the nastiest conflict class there is: not textual (git resolves that) but compositional — each diff fine alone, the combination breaking an invariant neither touched. The referee for that can't be either diff; it has to be a third document that states what the module is allowed to mean, which is exactly the seat
SPEC.mdoccupies in this design — the owning spec's invariants are what "both look reasonable" gets checked against, mechanically where the surface is concerned (check:spec-surface) and by the owning review where it isn't.The deeper half is the record-keeping: in journal terms, a merge is a fan-in — an event binding both consumed heads, so each side's assumptions (which spec version it read, which head it built on) are on the chain, not in the agent's chat history. That's what makes a later "these two changes were each fine and together wrong" derivable instead of archaeological: the conflict propagates to both parents as a precise path set. It won't make two reasonable agents agree — nothing does — but it makes their disagreement derivable: who assumed what, at which head, visible at the merge instead of discovered in production. That's the part I'd want to see in practice too, and it's checkable without trusting anyone's judgment of "reasonable."
Worktree isolation is a strong default, but it needs a clear promotion step. Having an agent produce a patch plus a short manifest of files changed and tests run makes review and merge the intentional handoff rather than an implicit side effect.
The worktree boundary raises a useful distinction: is “never touch your checkout” enforced by the host's filesystem permissions, or by routing the agent to a separate working directory? A worktree alone doesn't remove the process's access to sibling paths or shared credentials.
A small acceptance test could put a harmless sentinel outside the assigned worktree, ask the agent to modify it, and record both the tool denial and the unchanged sentinel. That would make the enforcement claim independently checkable alongside the spec/merge checks. I haven't run Thinkrail; does its current host enforce that boundary?