A fork of JetBrains/thinkrail. Upstream is a desktop-and-mobile
client for the pi coding agent. This
fork turns it into a workbench for more than one agent: Claude Code runs in its terminals as a first-class
agent, with its own configuration pane, IDE bridge, hooks, launcher and the workspace's spec tools reachable
over MCP.
ThinkRail is the agentic IDE that gets better every time you use it — learning your project through living specs today, and building its own capabilities tomorrow.
We built a rich interface around the pi
coding agent, isolated work into separate workspaces, and gave the agent durable project knowledge
through living specs and reusable skills. Next, we're adding full extension support, so ThinkRail can
create the tools it needs based on how you actually work.
Website: thinkrail.ai · Blog: thinkrail.ai/blog
A pi session and the change it made, scoped to an isolated git-worktree workspace.
- Isolated workspaces. Open any git repo as a project and cut workspaces from it as
git worktrees, each with its own branch and working directory. Agents work in parallel without touching your checkout; merge the good branch, delete the rest. You can also attach existing worktrees or explicitly work in the project folder itself. - A real IDE around the agent. A splittable workbench of Monaco editor tabs, a live git Changes view, terminals, and documents — all scoped to the active workspace. 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.
- Chats that stream like the engine thinks. Several concurrent
pisessions per workspace, each with its own model and live token and cost readout. Steer a running turn or queue a follow-up, delegate to subagents, and work a shared plan the agent updates and you edit — each completed step can be committed and reviewed on its own. - Specs as ground truth. A connected graph of
SPEC.mdfiles lives beside the code; the agent reads, searches, and maintains it through dedicatedspec_*tools, so intent survives the session. The read-only Specs tool renders the graph as a tree in the workbench. - Skills and workflows. Portable Agent Skills you already keep for other coding agents are read in
place, and 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. - Agent tools beyond the shell. Web research, and inline diagrams and option comparisons rendered right in the chat.
- Your providers, your credentials. Sign in with JetBrains AI or
connect any provider through
pi's own auth. ThinkRail has no accounts of its own. - Desktop app or browser. A native desktop app, or the
thinkrailCLI that opens the same app in your browser. Both embed the same engine host; app state lives under~/.thinkrail.
The project's spec graph as a tree, with the spec itself rendered alongside.
ThinkRail ships in two additive forms: a native desktop installer and the self-contained thinkrail CLI.
Both are published with SHA256SUMS on the releases page.
Download the thinkrail-desktop-* asset for your platform:
-
macOS (Apple Silicon) — open the DMG. There is no Intel desktop build.
-
Windows x64 — extract the complete setup ZIP, then run its setup executable in place, next to its payload.
-
Linux x64 / ARM64 — extract the setup tarball and run
installer. Desktop builds need glibc 2.38+ with GTK 3, WebKitGTK 4.1, Ayatana AppIndicator 3, and librsvg 2 — Ubuntu 24.04 or newer:sudo apt install libgtk-3-0 libwebkit2gtk-4.1-0 libayatana-appindicator3-1 librsvg2-2
Packaged stable and nightly desktop builds check for updates in the background and offer them in Settings → Updates: Download → Preparing update → Install & Restart. 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.
The installer downloads the right binary, verifies its SHA-256 checksum, and puts thinkrail on your PATH.
A plugin API. packages/plugin-api is the contract: a manifest, typed methods, channels and settings, a
pi-free tool definition for the agent and MCP surfaces, and host and web contexts. The server loads builtin
and external plugins, validates their wire traffic, serves their assets and feeds their pi resources into
every session; the web client loads a plugin's UI half, at build time for builtins or over the wire for an
external one. packages/ui is the shared UI kit plugins draw with. External plugins live under
~/.thinkrail/plugins/<id>/ or at the paths AppConfig.pluginPaths lists, and are enabled and disabled
while the app runs. A plugin defines a tool once and both a pi chat and a terminal agent (over MCP) can
call it. Plugins add side tools, launchers, tab decorations, file viewers, file icons, settings sections
and terminal accessories. See packages/plugin-api/SPEC.md and
packages/server/src/plugins/SPEC.md.
Nine builtin plugins, each one commit, each extractable to its own repository. Claude Code and Codex integrate terminal agents; the others add specification tools, viewers or presence:
| Plugin | What it adds |
|---|---|
plugin-spec-dialect |
the spec-graph read, the Specs side tool and the spec_* tool renderers |
plugin-blueprint |
the Blueprint interactive-spec format, its author and reactor |
plugin-claude-code |
Claude Code as the terminal agent: config pane, IDE bridge, hook status, launcher, terminal facts and picker driving, the shipped Claude marketplace |
plugin-codex |
OpenAI Codex as a terminal agent: config pane, launcher, hook status, /ide editor context and ThinkRail MCP tools |
plugin-discord |
Discord Rich Presence over local IPC |
plugin-branch-graph |
the project's Git Graph side tool |
plugin-visualize |
the terminal agent's live drawing surface, surfaced as an MCP tool |
plugin-file-icons |
material-icon-theme file-type glyphs |
The Git Graph side tool draws the project's branches and commits beside the terminal.
The Claude Code plugin bridges terminal agent sessions to ThinkRail's workspace and UI.
- The terminal bar drives Claude Code's interactive
/modelpicker and effort slider, and its Attach File button inserts workspace-relative@filepaths. - An IDE bridge feeds terminal events and facts into the app; hook status badges each tab, and resume works after a terminal is revived.
- The plugin ships its own Claude marketplace with a hook plugin, and keeps Claude's cached copy at the shipped version through Claude's own install and update commands.
- An agent that Claude Code starts, such as Codex, never takes over the tab.
![]() |
![]() |
![]() |
![]() |
![]() |
|
The Context tab displays active instructions across global ~/.claude/CLAUDE.md, project CLAUDE.md, referenced AGENTS.md files and launch flags, with live size accounting. The Account tab shows session and weekly usage limits and the CLI version. The Capabilities tab lists installed plugins, skills, hooks and ThinkRail's loopback MCP server, and moves any capability between User, Project and Local scope. Settings are edited in place, and each change asks which settings file it goes to and shows the diff before it is written.
The Codex plugin runs the Codex CLI in a terminal the way Claude Code runs.
- A right-click launcher offers continue, resume or fork, sandbox choice, reasoning effort and web search.- Tab status comes from Codex's own lifecycle hooks, installed once into
~/.codex/hooks.jsonand inert outside a ThinkRail terminal. - The model chip switches a running session's model for that session only, never saving a new default.
- An IDE bridge speaks Codex's
ide-contextprotocol, so/idesees the open files, the active file and the selection without the VS Code extension. - The config pane resolves project, user and system
config.tomlwith provenance, shows theAGENTS.mdchain, and edits values in place by TOML type, each key linking to Codex's configuration reference.
![]() |
![]() |
Configuration discovery covers the user, system and worktree-root files; profiles and nested project
configuration are not modelled. See packages/plugin-codex/SPEC.md for
the current scope and limitations.
- Blueprint pairs agent authoring with an interactive spec viewer for terminal agents and
pichats. The agent writesBLUEPRINT.mdand verifies it with theblueprint_checkMCP tool; the viewer renders decision cards, option selectors and rationale blocks live. It builds on the spec dialect, which owns the Specs panel and thespec_*tools for every session and sub-agent. - The terminal visualization plugin gives the agent a
visualizetool: it draws, publishes, then waits for your verdict. Drawings persist per terminal. - The Git Graph draws commit lanes, is hidden in a folder with no history, and scopes the Changes panel when you click a commit.
- Discord Rich Presence is off by default, with a blocklist of projects and a switch for showing file names.
- File icons use recoloured material-icon-theme glyphs, with a fallback when the plugin is off.
Kept as atomic commits so each can become a pull request:
- Projects and files: open a plain folder as a project without git, clone a repository URL into a project, search the whole workspace from one popup, create, rename, drag and trash files in the tree, reveal a file in the file manager, and a notice when an open file is deleted on disk.
- Editing and previews: an outline column that drives preview and source, frontmatter as an Obsidian-style properties block, Cmd+F in every preview, zoomable inline diagrams, a code font of your choice with ligatures, and an editor selection sent into a pi chat.
- Workbench: vertical tabs under their workspace, a frame that belongs to its project, branch pickers that show every remote, and a desktop window that returns to its port with its tabs.
- Terminals and agents: the spec tools reachable by any terminal agent over MCP, a terminal that thaws after a lost drain event, a pty that no longer inherits a stale utmpx user, live reattach that restores full-screen input modes, and a default model, hidden models and JetBrains AI org switching in Settings.
The fork is developed and tested on macOS only. Other platforms build, but nothing here has been run on them.
Prerequisites: Bun 1.4, Node.js 22.19 or newer, git on PATH, and an authenticated pi provider. App
state lives under ~/.thinkrail.
curl -fsSL https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.sh | bashWindows — the same command works 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-repothinkrail needs git on your PATH and a model provider — sign in with JetBrains AI from the app or use
your own provider credentials. thinkrail --help lists the flags; thinkrail --version prints the build.
Nightly builds, pinned versions, updates, and uninstall
The installer takes --channel stable|nightly and --version; a pinned version must belong to the
selected channel:
curl -fsSL https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.sh | bash -s -- --channel nightly
curl -fsSL https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.sh | bash -s -- --channel stable --version 0.1.2
curl -fsSL https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.sh | bash -s -- --channel nightly --version 0.2.0-nightly.10On Windows the options are environment variables (THINKRAIL_CHANNEL, THINKRAIL_VERSION,
THINKRAIL_PREFIX, THINKRAIL_NO_MODIFY_PATH):
$env:THINKRAIL_CHANNEL='nightly'; irm https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.ps1 | iex # PowerShell
set "THINKRAIL_CHANNEL=stable" && set "THINKRAIL_VERSION=0.1.2" && powershell -c "irm https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.ps1 | iex" # cmdInstalled stable and nightly CLI hosts periodically offer Run Update in Settings → Updates. It runs
the host machine's thinkrail update in the background — also when the UI is open in a browser on another
machine — and a successful update asks you to restart the host manually. You can run thinkrail update
directly on any platform: it re-runs the installer for the installed channel and replaces
<prefix>/bin/thinkrail[.exe]; pass --channel or --version only for an explicit override.
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 — --remove-data deletes it,
-y skips the questions).
Prefer a manual install? Download a binary and SHA256SUMS from the releases page and verify the checksum.
For self-update to work, rename it to thinkrail (thinkrail.exe on Windows) and place it at
<prefix>/bin/thinkrail[.exe]; a binary kept under its release filename or elsewhere must be replaced
manually or reinstalled with the script.
| Platform | Desktop | CLI |
|---|---|---|
| macOS Apple Silicon | DMG | signed binary |
| macOS Intel | no Electrobun build | not prebuilt — build from source |
| Windows x64 | signed setup executable | signed .exe |
| Linux x64 / ARM64 | setup tarball, unsigned | unsigned |
JetBrains signs the Windows CLI and desktop setup executable. The macOS CLI is signed but not yet notarized. Signed and notarized desktop DMGs require the coordinated JetBrains service pipeline; older published DMGs and locally built packages may still be unsigned and blocked by Gatekeeper. Linux artifacts are unsigned.
CommanderTvis fork builds omit the analytics key and send no usage analytics or installation attribution. The behavior below describes upstream builds configured with an analytics key.
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. Additional product usage 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. When launching from
the command line, thinkrail --no-analytics (or 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 here — only where you accepted marketing cookies on the
website or no consent is required — and that link expires after 30 days.
ThinkRail is a thin host that runs pi in-process and bridges it to a rich web UI. 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. Three rings:
- Engine host —
packages/server(+packages/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.
goal-and-requirements.md and architecture.md are the
canonical product and design specs. ThinkRail is developed spec-first: a SPEC.md sits beside every
module, and a change that moves a boundary, contract, or decision updates the spec in the same change.
You need Bun 1.4.0 (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.
git clone https://github.com/JetBrains/thinkrail.git
cd thinkrail
bun install
bun run dev # host + web client together; Ctrl+C stops bothbun run dev # host + web client in the browser, with hot reloadCONTRIBUTING.md covers the checks, the end-to-end suites, desktop packaging, and the
repository layout.
Contributions are welcome — see CONTRIBUTING.md. This project and community are
governed by the Code of Conduct.
Licensed under the Apache License 2.0.








