I read the repo before I installed the local build. Reading the source turned up one thing that surprised me more than any of its features: the editor in this “IDE” is read-only.

Line 110 of monacoSetup.ts says readOnly: true, with a hint string to go with it. I opened the UI and tried typing into it. Not a single character went in, and the file hash didn’t change.

This post is about that one thing: an IDE that won’t let you edit code, and what exactly it’s betting on.

It Isn’t the Next IntelliJ

The repo is at JetBrains/thinkrail, Apache-2.0, with a “JetBrains incubator project” badge on the README.

Their own description is one sentence: use pi to do vibe coding in this lightweight IDE, and it customizes itself around the way you work.

What’s pi? A third-party minimal agent harness, package name @earendil-works/pi-coding-agent, from the Earendil folks. Its philosophy is “no features, just primitives”. Sub-agents, plan mode, permission prompts, none of it is built in. You write your own extensions.

What ThinkRail does is wrap that command-line agent in a full interface: workspace, editor, diff, terminal, spec tree.

So what you’re looking at is a company of a couple thousand people writing a shell in TypeScript to wrap an agent that somebody else wrote. That’s a different road from the one IntelliJ took with its own kernel.

Installing It Means a 218 MB File

It comes in two shapes: a desktop installer, and a self-contained command line build.

I downloaded the CLI version. A single 218 MB file with a Bun runtime stuffed inside, so you don’t have to install node first. Running it looks like this:

./thinkrail --no-open --port 24242 <your repo path>

Open localhost:24242 in a browser and you get the full interface. There’s no account system of its own. Models come from pi’s config.

I was all set to go into settings and paste a DeepSeek key, and then the Providers page opened with a line already sitting there: DeepSeek, env key DEEPSEEK_API_KEY, connected.

It had read the connection pi already had configured in my shell environment. Zero setup.

I Gave It a Broken Repo

I prepared the test case on purpose: a small JS library that turns titles into URL slugs, with one of its two tests red because the implementation doesn’t handle punctuation.

The landing page has three options: write specs, start work directly, or work inside the project directory. I clicked the first one, which is its signature flow.

I kept the prompt restrained: write out the specs as things stand, don’t change any code yet.

After I hit create, the first thing it did was cut a real git worktree at ~/.thinkrail/worktrees/demo-repo/workspace-1, on a branch called write-slug-lib-specs. I went back to the main repo to check. main was still on the same commit, not a hair moved.

This step isn’t simulated. git worktree list shows two lines.

Six Minutes Seventeen Seconds, Three Files

When it finished I looked at the numbers: 6 minutes 17 seconds, 26 tool calls, 15 steps, with three spec_create, three file reads, and three file edits. It used 5.3% of a one million token context and cost 0.138 dollars.

It didn’t start writing right away. First ls to see the structure, read the README, read the tests, then it actually ran node --test, saw that red test, and only then started writing.

Three markdown files came out:

goal-and-requirements.md covers what the library is, who it’s for, and that for now it only does “lowercase plus spaces to hyphens”. architecture.md covers the single-module topology, with dependencies going only from tests to source. src/SPEC.md covers the slugify contract and its boundaries.

All three carry frontmatter, id, type, status: draft and parent, strung together into a graph. That’s not a format I taught it. It’s the fixed rule from the spec-graph skill pack it loads.

The most interesting part is how it handled that red test. It didn’t write “strips punctuation” down as a capability that already works. Instead it opened a separate section in the module spec called “Known limitation” and spelled it out: the test expects hello-world, the function returns hello,-world!, punctuation left as is.

When it was done it ran spec_validate itself. It passed.

What the Spec Graph Looks Like

The three files aren’t documents sitting side by side. They’re a tree with parent pointers.

The root is the goal document, the middle is architecture, the leaves are specs for individual modules. The right column in the UI is that tree. Click a node and the editor on the left renders the file, with Preview and Source views.

Their blog post “Spec-Driven Development” says the point is to let intent outlive the session. Close the chat and the code is still there, but the “why it’s written this way” usually disappears along with the chat. Specs keep that part around, and the agent reads the whole graph in at the start of every run.

This time I only had it write, not edit. When it does edit, it reads the same graph.

Then I Found the Read-Only Thing

After it finished I wanted to change a sentence myself, so I clicked into the Source view of src/SPEC.md, selected a line, and pressed a key.

Nothing. I assumed it was a focus problem, clicked a few times, then tried shoving text straight into the editable region with devtools. Same conclusion: input doesn’t go in, and the file hash on disk is identical before and after.

So I went back to the source for the answer, and it’s that readOnly: true from the top of this post. The UI even has a hint prepared, telling you to have the agent make the change.

Someone raised this on Hacker News, saying the chat panel is the lead actor in ThinkRail and the editor and file tree are supporting cast, that “you’re not even allowed to edit files by hand”.

I checked it, and it’s true. In fairness though: the terminal works. There’s a real PTY at the bottom, and nobody stops you from running vim in it. Only that Monaco panel is locked.

The problem is that this design swaps out the subject of “changing code”. In an old IDE, you and the agent each own half of that. Here the division of labor is clear: the agent writes, you review.

Why It Dares to Design It This Way

Because in its architecture, the IDE part was never the point.

The official architecture doc splits the system into three rings: the engine host, the protocol line, and the UI client.

The first ring runs in packages/server, using Bun to start an HTTP + WebSocket service with pi running in-process. The second ring is the versioned protocol in packages/contracts, the only coupling between the two ends. The third ring is apps/web, a React client that is mobile first.

“Mobile first” is not a figure of speech. The doc says so: the UI ships independently of the host, dials into a host over the network, and a phone can connect through Tailscale.

So from day one it never designed itself as a traditional IDE. It’s a remote panel for an agent host, and the desktop build just happens to wrap it in Electrobun.

The read-only editor isn’t a crippled editor. It’s the natural result of that architecture: the UI is only the observer and the approver, and the thing that actually does the work is the agent inside the host.

The Repo Itself

The codebase isn’t small: 1,493 TypeScript files plus 349 TSX files, 354,000 lines.

The stack is new too: Bun runtime, React 19, Monaco 0.57 with shiki, xterm 6, Tailwind 4, TypeScript 6.0.3, Astro for the site. The desktop shell isn’t Electron, it’s Electrobun.

Community numbers: 7,484 stars, 450 forks, 365 open issues. The repo was created on July 8, 2026, and it got there in under four months. That’s a fast pace.

Releases are dense too: 0.2.0 on October 18, 0.3.0 on October 29, 0.3.1 on November 1, and the nightlies are already at 0.4.0.

Two Things That Don’t Sound Good

First, telemetry is on by default. analyticsEnabled and analyticsConsentConfirmed are both true in config.json. That --no-analytics launch flag only turns off “additional usage data”, not the basic stats, so you have to go into settings to kill those.

Second, JetBrains’ AI strategy is a bit scattered right now. The two Hacker News threads together have over two hundred points and over two hundred comments, and the top voted one isn’t praise, it’s a complaint: Air and ThinkRail are both still half finished, while the AI Assistant that actually works well got pushed to the side.

I agree with that one. ThinkRail feels more like a bet, an experiment. JetBrains itself hangs the incubator sign on it.

My Call

If your first reaction is “what use is an IDE that won’t let you edit”, then it really wasn’t built for you.

It serves a different group: people already used to letting the agent do the work, whose main job is reviewing diffs and writing specs, moving forward one session after another. For them, being able to edit is actually a burden, because when you and the agent are fighting over the same file, the conflict can only be settled by self-discipline.

The answer it gives is physical isolation: one worktree and one branch per workspace, so the agent’s mess stays on its own branch, and you merge only after you’ve reviewed it.

I think that idea is more thorough than “add an AI button to the editor”. Its bet is that the IDE of the future is mainly for review, not for writing.

Whether the bet is right, check back in a year. As for this version, I’ll use it for small jobs. I won’t use it to replace IDEA.

When you write code these days, is that moment of changing a file still mostly your own hands, or has it already gone to the agent? If it’s the latter, this read-only design probably won’t bother you.

That means anyone who can sit in the middle of your network can sign a “trusted” certificate with one of those keys and impersonate the services JetBrains tools talk to.

JetBrains published two advisories on October 30. One covers what to do about the IDEs, the other is a status table across the product line. I read through the coverage in Chinese, and it was all paraphrase. Nobody actually went and checked their machine.

This post is that check, written as a manual. Everything runs locally, and nothing in here changes your configuration.

What the advisory actually says

The affected components are the ones that run on Java: the IDEs, Toolbox, Gateway, ReSharper. They trust the trust store shipped inside the bundled JetBrains Runtime, not the macOS Keychain.

The advisory is blunt about one thing: updating your operating system does not protect you here.

The fixed JBR no longer trusts these four root certificates: emSign ECC Root CA G3, emSign Root CA G1, emSign Root CA G2, and AAA Certificate Services.

Under the hood that is four CVEs. CVE-2026-91403 and CVE-2026-114820 are Oracle’s fixes inside the JBR. CVE-2026-118696 covers the embedded browser JCEF taking Chrome’s certificate revocation list. CVE-2026-118697 covers the background service jetbrainsd and its own bundled list.

Three layers, each fixed separately.

Step one: check whether your versions even line up

Don’t start deleting certificates. First find out which build you are running. A JetBrains .app carries an Info.plist, and the build number is in it.

/usr/libexec/PlistBuddy -c 'Print :CFBundleShortVersionString' \
  "/Applications/Android Studio.app/Contents/Info.plist"
/usr/libexec/PlistBuddy -c 'Print :CFBundleVersion' \
  "/Applications/Android Studio.app/Contents/Info.plist"

Swap the path for whichever IDE you have. Toolbox installs live under ~/Applications.

On my machine:

• IntelliJ IDEA 2026.2.3, build IU-262.10968.63, bundled JBR 25.0.4+1-508.27
• Android Studio 2026.2, build AI-262.9437.185.2621.16467767, JBR 25.0.3
• JetBrains Toolbox 3.9.1, build 3.9.1.89198

Cross-checking against the fixed-version list: IDEA has to be 2026.2.4 to count as fixed, and I am on 2026.2.3, one patch short. Toolbox 3.9.1 is on the list, so that one passes.

Android Studio is a blank spot. It is not in JetBrains’ table at all, and I could not find an equivalent Google advisory, so I checked the JBR version myself: 25.0.3, while the fixed JBR 25 builds are 635.79, 508.41, and 329.142. 25.0.3 is obviously old.

Step two: just ask the trust store how many are left

Version numbers can lie. Trust stores cannot. Every JBR ships a cacerts file, and its own keytool will list it.

"/Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/keytool" \
  -list -cacerts -storepass changeit | grep -iE "emsign|comodo"

Android Studio returns four lines:

• comodoaaaca [jdk]
• emsigneccrootcag3 [jdk]
• emsignrootcag1 [jdk]
• emsignrootcag2 [jdk]

All four are there. IntelliJ IDEA’s copy is the same, all four present, 111 certificates in total.

There is a trap here I have to mention, because I walked into it: the alias as printed carries a space and a bracketed suffix, emsigneccrootcag3 [jdk]. If you type just emsigneccrootcag3 to delete it, keytool tells you no such alias exists, even though it is sitting right there in the list.

Step three: prove your fix actually took effect

This is the step the official documentation does not have.

The official workaround is: copy the cacerts file, delete the affected roots, then point the IDE at the copy with a VM option. The problem is knowing whether that -Djavax.net.ssl.trustStore actually got loaded. A wrong path, a missing slash, a ~ that never expands, and it fails silently.

So I wrote a thirty-line program that asks the JVM directly: how many of these do you still trust?

The key line is tmf.init((KeyStore) null), which makes the JVM use its default trust store, the one that honours javax.net.ssl.trustStore. Then you count how many issuers in getAcceptedIssuers() are named emSign or AAA Certificate Services.

Here is what came out:

With no VM option, it reports 109 certificates and 4 hits. Pointed at the officially cleaned copy, 107 and 2 hits. With all four removed, 105 and 0 hits.

Three numbers, and the gap between “I think I fixed it” and “I did fix it” closes.

Two things the advisory does not tell you

First: the official workaround removes two aliases, comodoaaaca [jdk] and emsigneccrootcag3 [jdk].

But what I found on my machine was all four present, G1 and G2 included. After deleting those two, my probe still reported two hits. So if you follow the two documented steps on this machine, two eMudhra root certificates stay behind.

I am not in a position to explain why JetBrains listed only two. Maybe the fixed runtime handles G1 and G2 elsewhere, maybe they were being conservative. On the plain question of what is on the machine, the number is four, not two. If you want to be thorough, delete all four; I measured 105 certificates and zero hits afterwards.

Second: macOS’s own system roots still contain these two.

emSign ECC Root CA - G3 has SHA-1 3043FA4FF257DCA0C380EE2E58EA78B23FE6BBC1, and emSign Root CA - G1 has 8AC7AD8F73AC4EC1B5754DA540F4FCCF7CB58E8C.

security dump-trust-settings shows no per-certificate distrust policy in either the system or the user domain. That does not mean macOS is letting them through, TLS has other mechanisms, but from the Keychain side at least, they are still there.

While you are at it, scan the other JVMs

This is the part most people will miss.

JetBrains only speaks for its own products. But your Gradle daemon runs on some JDK, your command-line Kotlin compile uses some JDK, Homebrew installed another one, and every single one has its own cacerts, unrelated to the IDE’s.

I walked every JVM on the machine that can run keytool:

• Homebrew OpenJDK 21.0.10, 109 certificates, all four present
• Android Studio’s bundled JBR 25.0.3, 109 certificates, all four present
• IntelliJ IDEA’s bundled JBR 25.0.4, 111 certificates, all four present

Not one of them is fixed.

JetBrains also shipped fixed JBR builds on two jbr21 lines, 21.0.11b1163.125 and 21.0.9b1038.91. When upstream OpenJDK catches up I have no first-hand source for, so I will not draw that conclusion for you. All I can say is that the 21.0.10 on this machine still has all four.

What to do

The priority order is obvious: upgrade if you can, and skip the workarounds.

IDEA 2026.2.4 shipped on October 30; I checked the date against JetBrains’ release API. Toolbox 3.9.1 is already installed, and I checked jetbrainsd too, which runs 0.9.9728, the fixed version. So the only thing left to touch is the IDE itself.

If you cannot upgrade yet, the official three steps are: copy cacerts, delete the aliases with the keytool from that jbr, then add a line to Help → Edit Custom VM Options with -Djavax.net.ssl.trustStore= pointing at the copy.

The path has to be absolute. No ~, no quotes. Get it wrong and it will not complain, it just silently does nothing. Then confirm in Settings → Server Certificates that automatically accepting untrusted certificates is off.

One more detail: the JCEF embedded browser’s certificate list cannot be changed, so on 2025.2.6.4 and earlier you have to turn it off entirely with the registry key ide.browser.jcef.enabled. Markdown previews and notebook output stop working when you do, so remember to turn it back on after you upgrade.

My take

The thing worth remembering here is not which version got fixed. It is where your trust boundaries actually are.

You updated macOS, so you assume you are safe. You updated Chrome, so you assume you are safe. But the IDE carries its own trust store, Gradle has another one, and the JDK on your command line has a third. Each one needs its own fix.

A security advisory is written for everyone. It will never answer “what state is this specific machine in.” That answer only comes out if you run it yourself.

How many JVMs are on your machine right now? Go scan them. I would bet more than one still has all four.

The conclusion in one line: the benchmarks you use to grade agents today aren’t measuring how people actually use them.

In SWE-Bench Pro, 93.8% of tasks are feature additions and bug fixes, and every task arrives as one complete message. The agent sees the whole picture at once and then starts working.

In real sessions, feature additions are only 19%, bug fixes 26%. Together they don’t add up to half.

So what’s the rest? 6% asking how the code works, 10% general programming questions, plus planning, code review, refactoring, running commands, debugging. None of that exists in SWE-Bench Pro, because that benchmark’s task definition has no such action as “asking a quick question.”

Half the sessions are a single message

They counted every session by number of user messages.

50.9% of sessions have just one message, 16.2% have two, 8.8% have three, and everything from four up to five adds up to under 15%.

So the rest of the analysis only looks at the 33% with at least three messages, which they call long sessions — a single message is a one-shot Q&A. Inside long sessions, the breakdown looks like this: 6% asking about the project’s own code, 10% general programming questions, and the rest scattered across planning, review, refactoring, debugging, execution — feature additions and bug fixes have been diluted down to a small slice.

Run SWE-Bench Pro through the same classifier and you get 55% feature additions, 39% bug fixes, 6% refactoring. That’s it.

Three public corpora, three completely different patterns

They also ran the same labeling on three public agent conversation sets.

SpecStory is a public export of IDE sessions. 521 of its 1,000 are long sessions, the closest to their own data, with a noticeably high share of planning.

DataClaw is a community-shared set of sessions, 585 long ones, almost all execution and short commands. SWE-chat is records of real users in a chat interface, 698 long sessions, predominantly execution and planning.

The three datasets come from different products, different users, different collection methods, so they don’t compare volumes. But one thing is hard fact: calibrate a benchmark against any one of them and you get a different task mix, and that difference isn’t something sample size can wash out.

Not even their own 4,782 count as ground truth. In their words, you have to pick a target first and then declare it; there is no default one.

That sentence is the whole skeleton of the study. Everyone used to assume “building tasks from GitHub issues is what’s real.” This paper says no — issues are just one slice of one population. Swap the population and the data takes on a different shape, and nobody is in a position to call their own slice the standard.

They didn’t build a new benchmark, they retrofitted the old one

Building an interactive benchmark from scratch means throwing away all the repos, environments, and tests SWE-Bench has accumulated over the years. So they took another route: keep the tasks, repos, tests, and original requirements, and only rewrite the user messages.

The method is to split each issue into three ordered requests, with zero invented content allowed. Each request has to be actionable against the code state the previous one left behind, identifiers and code snippets stay verbatim, and after splitting another model checks for any dropped requirements. Of the 731 public SWE-Bench Pro issues, 31 failed validation, leaving 700.

Those 700 are the entire battlefield. Every number from here on comes from them.

The original issue is roughly a thousand words in one message, all crammed into a single block. After splitting it looks like this — the first sentence gives only the main symptom, edge cases wait for the second and third.

qutebrowser had an issue where LinkedIn wouldn’t load, caused by an older QtWebEngine missing Array.prototype.at.

The first request just says “fix LinkedIn failing to load on macOS with QtWebEngine 5.15.2, and catch it with a polyfill.”

Only the second one adds “it must cover versions before 6.3 that lack native support, and both positive and negative indices have to be correct.” The third only then says “out-of-range must return undefined, and only inject when the native method is missing.”

Line the three up and the complete spec from one message has been spread into three rounds of progressive disclosure.

They also injected “ask about the project itself” questions

In real sessions, 6% is asking how the project’s code works, and issue benchmarks have none of that. So they had a model read the repo plus a trajectory where the problem had already been solved, and generate one to three questions.

Each question carries two things: a reference answer, and an evidence script that actually runs. During dataset construction it’s run against a clean repo — if it produces no evidence, or it modifies the repo, the question is dropped.

That rule conveniently eliminates a whole class of questions: ones whose answer isn’t in the code (“why was it designed this way back then”) are physically impossible to produce.

The qutebrowser task later got a companion question whose answer named two config entries and touched five files.

After splitting: cost doubles, scores don’t move

Here’s the most valuable part of the whole paper: four models, 700 tasks, three feeding modes, three runs of each.

Single-shot means throwing the original issue over as one message. Split means sending the three requests in sequence, with nothing added in between. Split plus Q&A means also adding those repo questions, with an optimizer choosing where they go.

The result: splitting raised each model’s cost 2.0 to 2.6 times.

Same repos, same tests, not a single added requirement — all the extra money went into “requirements arriving in batches.”

Scores barely moved. GPT-5.6 Terra stayed flat; the other three dropped 4 to 5 points on average, roughly the same as the variance from running the same setting three times.

They also ran a control: splice the three rewritten requests back into one message and send that. All three GPT models’ cost and scores landed right back in the single-shot bucket. So the expense is in the act of sending three times, not in the rewording.

Splitting gives you intermediate checkpoints

Run one long requirement to the end and you get a single final score, with right and wrong smeared together — if you want to know which step collapsed, you have to go dig through the trajectory yourself. Split into three steps and you can run the tests after each one, scoring only against the requirements revealed so far, and the failing step is visible at a glance.

In an ablation over 64 tasks, the pass rate and test pass rate climbed with each request. One problem becomes several verifiable checkpoints, and diagnosis gets much clearer.

This is probably the only benefit of splitting. Beyond it, splitting is pure cost.

What it hasn’t solved

They only generated two kinds of messages: split requirements, and questions about the repo. Planning, review, execution, and debugging without a fix, all of which show up in real sessions, still have no generator — and for most of them, even “how do you automatically judge correct from incorrect” hasn’t been worked out.

One more thing: every message is frozen before the run starts. Reproducibility is real, and so is the fact that the “user” never changes their mind in response to the agent.

The research stops there. The things they listed as not done go on for a while, right down to admitting a weakness like “the classifier has no human-labeled accuracy set.”

What this means if you write code

When you look at a model leaderboard, you assume that number means “how good it is at writing code.” What this paper says is that the number also contains something you’ve never been choosing: the pace at which it’s asked to work.

Same model, requirements delivered all at once versus in three batches — more than double the cost, roughly the same score. So how you ask for things on your own project is a separate question, and it’s the one you control. My habit is to write background, goal, and constraints all in one message. Reading this hasn’t changed my mind. When cost actually becomes the sticking point, the first thing I look at is how many extra steps it took, not whether it got the answer right.

One fun corollary: if every benchmark measures “everything delivered at once,” the models being trained will get used to that pace too, and then nobody can measure the follow-up questions, the course corrections, the progressive disclosure that real sessions are full of.

Think back to your last few agent sessions — how many were solved in one message, and how many took several rounds back and forth?