ThinkRail: A Worktree-First IDE for Coding Agents

Running a coding agent in your main checkout is convenient until an experiment collides with another change. ThinkRail puts each task in a Git worktree, then brings the agent conversation, files, terminal, and diff together around that workspace. It is an Apache-2.0 project from JetBrains InnovationHub built around the pi coding agent.

This is a look at an established project as a useful discovery, based on its documentation rather than a hands-on test. Its combination of worktrees and versioned project specs makes it worth exploring if you juggle several agent-assisted changes.

A workspace for each line of work

A Git worktree is another working directory attached to the same repository. ThinkRail describes a project as a local Git repository and a workspace as a worktree with its own branch and working directory. You can create separate workspaces for a bug fix and an experiment, review each diff, and decide which branch to keep. The project also supports attaching existing worktrees or explicitly working in the project folder itself. The repository README describes those options.

Worktrees separate checked-out files and branches; they do not automatically isolate databases, network services, credentials, or ports. Two agents running integration tests can still collide if their test environments share those resources. Give parallel tasks separate resources where necessary, and review changes before merging.

The IDE around the agent

ThinkRail combines Monaco editor tabs, a file tree, terminals, and Git changes with pi sessions. According to the project, sessions can use different models and show token and cost information, while a running turn can be steered or given a queued follow-up. The interface also supports comments anchored to files and diffs that can be sent to a chat as context.

That layout gives a reviewer a useful loop: give the agent a bounded task, inspect the diff, run relevant checks in the workspace terminal, and send a specific correction. A clean diff and passing tests still need review against the original requirements; a model’s explanation is not evidence that the code works.

Specs that travel with the code

ThinkRail’s distinctive idea is a graph of Markdown SPEC.md files stored alongside the code. The project site describes links between goals, architecture, modules, and tasks, with dedicated tools for the agent to search and maintain the graph. Because the files live in the repository, their changes can be reviewed with the code that motivated them.

This can help retain decisions across sessions, but only if the specs stay accurate. Review spec changes like any other patch: an agent can misunderstand a requirement or update a document to match an incorrect implementation. For a small experiment, a short task description may be enough; a spec graph earns its place when several changes need shared context over time.

Trying it safely

The project offers desktop builds and a command-line launcher that opens the browser interface. Its README lists macOS, Windows, and Linux requirements, downloadable release assets and checksums. The launcher needs Git and an authenticated model provider; provider usage may have its own charges. Read the installation instructions and releases for the current platform requirements before installing.

Start with a disposable branch in a repository you can recover. Create a workspace, ask for a small change with clear acceptance criteria, then inspect the file changes and run the project’s own tests. Check what the agent is allowed to access, including credentials and connected tools, before giving it broader tasks. ThinkRail documents approval controls for MCP calls, but those controls do not replace reviewing each server and its permissions.

ThinkRail is a useful fit when the overhead of coordinating branches and agent context is getting in your way. If you already have a comfortable terminal workflow, the tradeoff is another application and its conventions. Try it on one contained task and judge whether its workspace and spec views make review easier for your team.