ThinkRail: a JetBrains incubator IDE that runs the pi agent in-process

What ThinkRail actually hosts, and for whom

ThinkRail does not implement a coding agent. The README states that pi owns models, skills, compaction, cost, and session state, while the app owns the workspace, the editor, and the wire. That division is the whole product thesis. If you are already running pi from a terminal and want the agent to sit next to a Monaco editor, a git Changes view, terminals, and a spec-graph viewer, ThinkRail is the shell that puts those in one window. If you are looking for a new agent runtime, this is not it.

The intended user is someone who treats a git repository as the unit of work and wants more than one agent session alive at a time. V1 is described as a Worktree IDE: you open a repo as a project, and each workspace is a git worktree with its own branch and working directory. Multiple concurrent pi chat sessions are scoped to the active worktree. That scoping is the interesting design decision. It means the agent's context boundary is a checkout, not a global conversation, which matches how a lot of people already isolate tasks even without an agent involved.

The README also points at a vibecoder-focused experience on the project site, and the site itself is described as a landing page that is the IDE. That is a marketing posture more than an architecture fact, but it tells you who the project is talking to: people who want to start from a prompt and a repo rather than from a build system.

The three-ring architecture and what crosses each boundary

The repository is organized as three rings. The engine host is packages/server plus packages/shared, launched by either apps/cli or apps/desktop. createServer() is a Bun.serve HTTP and WebSocket host, and it holds an AgentSessionManager that keeps one in-process pi AgentSession per tab. The wire is packages/contracts, described as a typed, versioned protocol that is types-only. The UI client is apps/web, a mobile-first React 19 plus Zustand plus Tailwind v4 application that dials a host over the wire.

The dependency direction is the part worth noting. apps/web depends on packages/contracts only, never on the server. That is what lets the UI ship on its own, and it is also a constraint: anything the UI needs from the backend has to be expressible in the protocol package. The contracts package being types-only means the wire definition has no runtime code, so version skew between a client and a host is a real category of problem the project has chosen to handle at the type level rather than by shipping shared runtime helpers.

The engine is pi only, run in-process through @earendil-works/pi-coding-agent. Running in-process rather than as a subprocess is a meaningful choice: it removes a process boundary and a serialization hop, but it also means the host's runtime has to satisfy pi's requirements. The README pins Node.js 22.19 or later as required by the in-process pi engine, and Bun 1.4.4 as the repository's package manager and runtime, which is why the two appear together in the prerequisites.

Getting a running instance: installers, CLI, and the dev loop

ThinkRail ships in two additive forms. The desktop installer is native, and the thinkrail CLI is self-contained and opens the same app in your browser. Both embed the same in-process agent host and are published with SHA256SUMS on the releases page. The CLI installer downloads the platform binary, verifies its SHA-256 checksum, and puts thinkrail on your PATH. On macOS or Linux, including Windows under Git Bash, the documented command is curl -fsSL https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.sh | bash. On Windows from cmd or PowerShell it is powershell -c "irm https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.ps1 | iex".

Channel and version selection differ by platform in a way that is easy to miss. On macOS and Linux you pass flags through the shell script, for example bash -s -- --channel nightly or bash -s -- --version 0.2.0. On Windows the same options are environment variables: THINKRAIL_CHANNEL, THINKRAIL_VERSION, THINKRAIL_PREFIX, and THINKRAIL_NO_MODIFY_PATH. Once installed, thinkrail update re-runs the installer for your channel, and on Windows it replaces the running thinkrail.exe in place. Removal is thinkrail uninstall, which takes out the executable, the PATH entry the installer added, and the install metadata. It asks whether to delete your ~/.thinkrail app state, keeps it by default, and accepts --remove-data to delete it or -y to skip the questions.

Runtime prerequisites are short: git on PATH, and an authenticated pi provider, because the agent runs against your real provider credentials. App state lives under ~/.thinkrail. To open a repo as a project, pass the path: thinkrail ~/code/my-repo. For development, the repository pins Bun 1.4.4 and Node 22.19 or later, then git clone, bun install, and bun run dev, which boots the host and the web client together and stops on Ctrl+C. The V1 launchers are separate: bun run --filter @thinkrail/cli dev for the browser launcher, bun run build:binary for a standalone CLI artifact, bun run desktop:dev to package and open the Electrobun app, and bun run desktop:build to package without opening it. Host-native installers come from bun run desktop:package:stable or bun run desktop:package:canary. Desktop commands use the standard Electrobun CLI and configuration; its pre-build hook builds the shared UI and stages ThinkRail's PI and native resources, while Electrobun owns preload bundling and installer creation. Native and installer smoke tests live in packages/artifact-tests, outside the application packages: bun run smoke:desktop after a dev build, and bun run smoke:desktop:installer <path> <stable|canary> for an artifact.

Signing, notarization, and the platforms that are missing

The README is unusually direct about code signing, and that directness is the most useful part of the install documentation. JetBrains signs the Windows CLI and the desktop setup executable. The macOS CLI is signed but not yet notarized. Signed and notarized desktop DMGs require what the README calls the coordinated JetBrains service pipeline, so older published DMGs and locally produced Electrobun packages may still be unsigned and blocked by Gatekeeper. Linux artifacts are unsigned. The README adds a warning that local installer smoke is not notarization verification, which is a fair distinction: passing a smoke test on your machine says nothing about whether a stranger's machine will accept the binary.

Platform coverage has a hole. Prebuilt targets are macOS on Apple Silicon, Linux arm64 and x64, and Windows x64. Intel macOS is not prebuilt; the README says to use Apple Silicon or build from source, and notes that Electrobun 2.0.1 does not provide a macOS Intel desktop build. The coordinated macOS release pipeline uses Electrobun's expanded app archive for JetBrains signing and SRE DMG finalization, and that intermediate archive is not a public download. The signing limitation stays until that private pipeline update is deployed, per the README.

Linux desktop builds carry their own prerequisites: Ubuntu 24.04 or another glibc 2.38 or later distribution with GTK 3, WebKitGTK 4.1, Ayatana AppIndicator 3, and librsvg 2. The README gives the Ubuntu 24.04 command: sudo apt install libgtk-3-0 libwebkit2gtk-4.1-0 libayatana-appindicator3-1 librsvg2-2. If your distribution ships an older glibc, the desktop build is not an option for you regardless of signing.

Where the worktree model breaks down

Scoping everything to a git worktree is a clean idea until your work is not shaped like a branch. A repository with a long-lived uncommitted scratch state, a monorepo where a single task touches three packages that share a lockfile, or a project that is not a git repository at all, all sit awkwardly against a model where a workspace is a worktree with its own cwd. The README frames the CLI around opening a git repo as a project, so the non-git case appears to be out of scope for V1 rather than handled by a fallback.

Worktrees also multiply disk usage and build caches. Each worktree is a separate checkout. For a large repository with a heavy install step, spinning up several concurrent workspaces means paying that cost several times. That is not a flaw in the design so much as a consequence of it, and it is the kind of thing you want to measure on your own repository before standardizing on the workflow.

The concurrency model has a related boundary. The AgentSessionManager keeps one in-process pi AgentSession per tab, and multiple concurrent pi chat sessions are scoped to the active worktree. Each session has its own model and live token and cost readout. The README states that pi owns cost, so that responsibility sits upstream, but it is worth confirming rather than assuming.

How this differs from driving pi in a terminal or a general editor

The obvious alternative is running pi directly from a shell. That gives you the same agent, the same models, the same skills, and the same session state, with none of the host in between. What you give up is the worktree-per-workspace structure, the tabbed Monaco editor bound to the active worktree, the git Changes view, and the spec-graph viewer. If your loop is already terminal-shaped, ThinkRail adds a browser or desktop process and a WebSocket wire and adds its own agent tools, though the questions and visualize tools are also published as plain pi packages for a vanilla pi.

The second alternative is an editor extension that talks to a coding agent over a subprocess or an API. The difference in approach is where the agent lives. ThinkRail runs pi in-process inside its own Bun.serve host, so the agent is not a child process the editor supervises and not a remote service the editor calls. That removes a boundary, but it also means the host process and the agent share a fate: the README's Node 22.19 requirement exists because the in-process pi engine needs it, and a host crash takes the sessions with it. A subprocess design would let the editor survive an agent failure, at the cost of a serialization layer.

The third point of comparison is the spec-graph viewer, which the README describes as read-only. The viewer is only one half: the README calls specs 'ground truth', a connected graph of SPEC.md files beside the code that the agent reads, searches and maintains through dedicated spec_* tools, so intent survives the session.

Release cadence, maintenance surface, and the licence

The release history is short: v0.3.1 on 2026-11-01, followed by v0.4.0-nightly.3 and v0.4.0-nightly.4 on 2026-11-02 and 2026-11-03. Nightly builds are a first-class channel with their own installer flag and their own desktop packaging script, bun run desktop:package:canary. A project that ships nightlies this early is telling you the stable line is thin. The README even shows an example pinned install at --version 0.2.0, already behind the current v0.3.1.

The maintenance surface for an adopter is the host plus the wire plus the UI, and the README is explicit that the UI ships independently and dials a host over the wire. That means a host upgrade and a client upgrade can drift, and the typed, versioned contracts package is the only thing standing between you and a mismatch. If you run the CLI against a browser tab you left open, that version skew is on you to manage.

On licensing: the repository is Apache-2.0. That is a permissive licence with an explicit patent grant and a requirement to preserve notices, but this is not legal advice and the obligations that matter to you depend on how you redistribute the binaries. The installers and desktop packages are published artifacts rather than source, and the README's signing notes mean the artifact you redistribute may be unsigned on Linux and, for macOS, signed but not notarized. Those are distribution facts, not licence facts, and they affect different audiences.

One more boundary worth naming: the README describes ThinkRail as a JetBrains incubator project. Incubator status plus a v0.x release line with nightlies alongside is a combination that argues for trying it on a scratch repository before pointing it at anything you care about. The README's own note that the macOS signing limitation remains until a private pipeline update is deployed is the clearest signal that the release infrastructure is still being assembled.

Editorial conclusion

Adopt ThinkRail if you already run pi against a real provider, work in git repos where one branch per task is normal, and want the agent sessions scoped to a worktree rather than to a single chat window. Skip it if you need Intel macOS builds, an unsigned Linux artifact you can hand to a non-technical teammate, or a stable release line: v0.3.1 landed on 2026-11-01 and 0.4.0 nightly builds ship alongside it. Before committing, verify three things in your own environment: that your pi provider is authenticated, that your distribution meets the Linux desktop prerequisites (glibc 2.38+, GTK 3, WebKitGTK 4.1, Ayatana AppIndicator 3, librsvg 2), and that the DMG or installer you download matches the signing state described in the README for your platform.

Frequently asked questions

Official sources

1. JetBrains/thinkrail on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases