v0.102

0.102

0.102 is the largest devrig and MCP Steroid release yet — 535 pre-release commits touching both halves of the product. The headline: devrig can now bootstrap a headless Remote Development backend entirely from an agent session, completing the capability goals of the product strategy. Beyond that, devrig — the CLI you install and run — grows one unified command surface where every steroid_* MCP tool is a subcommand generated from its own schema, keeps itself up to date automatically, installs the MCP Steroid plugin into your running IDEs, and downloads 14 JetBrains IDE products. The MCP Steroid plugin compiles steroid_execute_code scripts roughly 3×–10× faster with an in-process Kotlin compiler, returns machine-parseable results, is ready for IntelliJ 2026.3 EAP, loads on Android Studio, and picked up a long list of correctness, modality, and Windows fixes.

devrig is the recommended entry point. Direct use of the plugin's HTTP server is still supported (now explicitly marked deprecated in the settings UI), but devrig owns installation, the bundled Java runtime, agent registration, updates, and backend lifecycle.

One name, one home. This release completes a transition: what started as MCP Steroid at mcp-steroid.jonnyzzz.com now lives at devrig.dev — devrig is the product you install and run; MCP Steroid remains the name of the IDE plugin it talks to. The old host redirects permanently.

Breaking changes

• The applyPatch { } script DSL is removed (#206, #209): at eval scale it failed 64% of invocations. File edits go through the taught single-writeAction multi-edit recipe plus a new apply-unified-diff escape hatch built on the IDE's own patch engine.
• steroid_list_windows renames projectName / projectPath to snake_case project_name / project_path (#381), matching steroid_list_projects and the tool's own documentation. Consumers reading the old camelCase keys must switch.

Headless Remote Development backends — the strategy milestone

The essential change of 0.102: devrig can now launch a downloaded IDE as a headless managed Remote Development backend with MCP Steroid pre-provisioned — no desktop session, no attached client window. With it, the capability goals of the product strategy are all in place: devrig runs in headless environments end to end, so the full IDE — inspections, refactorings, debugger, test runs — is available to every agent wherever it executes, not only next to a developer's open desktop IDE.

• Agents bootstrap the whole discover → download → start flow themselves via the prompt articles and server instructions (#449); the backend lifecycle is hardened with pid-marker process tracking (a remoteDevelopmentBackend flag distinguishes backends from desktop IDEs, #451), single-instance locking, and artifact-safety checks (#411, #441).
• devrig mcp advertises a steroid capability statement at initialize, so schema-deferring harnesses (like Claude Code) learn the steroid_* surface before loading any tool schema (#428, #417).
• Clean-machine Claude/Codex Docker scenarios validate the workflow end to end. Background: devrig: MCP Steroid Goes Level 3 — Autonomous IDE Setup for AI Agents.

One devrig CLI, generated from the tools' own schemas

Every steroid_* MCP tool is now a first-class devrig subcommand auto-generated from its own schema metadata — adding a tool adds its command, and the served stdio MCP surface registers from the same canonical spec list, so the CLI and the MCP server can never drift (#284, #437, #356); a golden test pins the MCP wire unchanged.

• One Clikt tree for everything (#442): consistent help, aliases, and error handling; project listing is canonical list_projects (projects / project stay as aliases).
• Help that routes you (#450, #454): devrig --help is a compact index; the full tool reference moved to devrig tools; missing or invalid parameters route to focused help with the exact allowed values — and parse validation happens before any backend, file/stdin, or --out side effect.
• Exit codes follow sysexits (#437, #450): parse errors aggregate into one USAGE=64 message, internal faults exit SOFTWARE=70 with a stderr trace, and only I/O failures (plus an open_project --wait poll timeout) map to UNAVAILABLE=69.
• --json and --out you can build on: JSON payloads are real content[].json objects (no double-decoding for jq) in a shared {tool, command, isError, data} envelope; --out writes atomically and is accepted only where an image can exist; stdin and --*-file inputs reject malformed UTF-8, binary bytes, and >10 MiB payloads.
• open_project --wait polls until the canonical project path appears in list_projects, then returns the fresh project_name / backend_name / canonical path — and a failed open surfaces its error immediately.
• The whole surface is an authoritative contract in docs/devrig-cli-contract.md (#452), pinned by unit tests, a real-IDE Docker flow, and live Claude/Codex agent-usability experiments.

devrig keeps itself up to date

devrig now auto-updates (#270, #380): when the published version.json promotes a newer version, running sessions download and run the official installer, coordinated across concurrent devrig processes via per-pid marker files — simple by design: no lock files, no failure-count state, lower-pid-wins races, a stdout-purity test guarding the MCP channel (#373, #268 closed by this design). Design story: Install, Launch, Update: Shipping a CLI on Five Platforms — the devrig Approach.

• Launcher replacement handles Windows file locks (#385): a rename-aside, rustup-style sequence validated under real NTFS contention (locks that permit rename); an older devrig never overwrites a newer launcher thanks to a version header checked during self-heal (#374).
• Version numbers finally compare correctly (#360, #358): all build lanes share one token layout (releases are <base>.0-r-<hash>), compared by IntelliJ's VersionComparatorUtil ported into mcp-core (Apache 2.0, NOTICE shipped) — update notifications fire only when the promoted version is strictly newer than the current build.

The Kotlin compiler update: in-process compilation, 3×–10× faster

The fixed per-call Kotlin compiler startup — 7.8 seconds, 94% of wall time — is gone (#207). Snippet compilation moved onto the Kotlin Build Tools API (BTA) with one shared in-process build session per project (#361): the Kotlin daemon machinery is gone, the plugin no longer downloads a kotlinc distribution at all (the compiler jars ship in the plugin, 12→10 jars), and pinning the compiler environment per session cuts warm compiles from 367 ms to 218 ms. BTA is the lever that makes this optimization possible.

Yahor Berdnikau (@Tapchicoma) and the Kotlin team contributed this migration — thank you, Yahor and team, for the collaboration and the support along the way.

• Compiler messages are structured, remapped to user-code coordinates, and persisted for compilation errors and OOMs.
• In-process compilation also fixes Windows-side IDEs opening WSL-hosted projects (#78): no kotlinc subprocess to misroute into the WSL distro, and execution storage lives under ~/.mcp-steroid/runs off the \\wsl$ volume (#280) — the mcp.steroid.storage.path workaround is no longer needed.

Ready for IntelliJ 2026.3 EAP and Android Studio

• The bundled kotlinc is bumped 2.3.20 → 2.4.20-RC (the bump landed as 2.4.10, then pinned to the upstream BTA release candidate) so steroid_execute_code works on IntelliJ 2026.3 EAP while staying compatible with 2026.1/2026.2 (#357, #359); when an IDE's metadata outruns the bundled compiler, the plugin fails fast with one actionable message (#377).
• Scripts default to Kotlin language/API level 2.3 (up from 2.2) — the floor of the supported IDE range.
• The plugin and devrig emit JVM 21 bytecode (keeping the JDK 25 toolchain), so they load on Android Studio's bundled JBR 21 where v0.101 failed (#157, #181–#184); a class-file guard scans every shipped class, and an Android Studio Docker gate exercises the production plugin.

steroid_execute_code output is machine-parseable again

For successful executions, the tool result is exactly the execution_id: header plus your script's printed output — stage framing and progress lines no longer interleave with the payload, so a script printing a single JSON document parses again (#154, #159). Progress still flows to idea.log, MCP progress notifications, and the execution event log.

• The print-only output contract is taught everywhere: only printed output is returned (a bare trailing expression is ignored), and every recipe ends with a print. printToon's docs now describe its actual two-form contract (#459).

The host IDE's identity is back in list_projects / list_windows

Both list tools carry a backends[] lookup resolving each entry's backend_name to the host IDE's identity (#155) — a fresh IDE with zero open projects is identifiable with one cheap tool call:

"backends": [
  { "backend_name": "iu-47qi79c1",
    "intellij": { "name": "IntelliJ IDEA 2026.1.3", "version": "2026.1.3", "build": "IU-261.25134.95" } }
]

Migration: parsers reading the old top-level ide.* switch to backends[0].intellij. devrig's project / backend output carries the same identity keys in the same order.

steroid_execute_code reliability and IDE responsiveness

• Every execution is a visible, cancellable task in the IDE status bar, and a client disconnect cancels the script (#213, #229).
• findProjectFile accepts absolute paths and force-refreshes stale VFS entries — the #1 execute_code failure class (35% of eval failures) is fixed (#156); kotlinc diagnostics point at the agent's actual script lines (#221).
• waitForSmartMode returns a clear "INDEXING IN PROGRESS — keep polling" result instead of failing at its cap (#169); smart_non_modal waits out dialog-less modal progress (bounded, with progress notifications) while a real modal dialog still fails fast.
• One hung script can no longer wedge every other MCP tool into 60-second timeouts (#214), and a 31-second UI freeze from syncDocuments on the EDT is gone, with a fail-fast guard against reintroduction (#318).
• Three steroid_input / steroid_take_screenshot defects against modal dialogs are fixed (#309).
• Inspections are crash-isolated and cancellable: one crashing inspection no longer aborts the whole sweep; per-tool failures are reported in a structured failedTools section while the rest keep running (#93, #69, #94).

Execution history in one shared store — and we'd love to see yours

Execution history moved into collision-safe shared storage under ~/.mcp-steroid/runs with full backend provenance (#280, #433, #414); execution events route through a bounded serial write queue so log order is deterministic and a write failure fails the call honestly (#436).

Sharing that folder shapes the product: we are looking forward to your execution histories — real ~/.mcp-steroid/runs sessions are exactly what we analyze to adjust and fine-tune the tools, prompts, and recipes (how the learning loop works, what to send and how). We also welcome proof-of-concept customers and enterprise partners — to have devrig evaluated on your repositories with us, see how you can help and get in touch.

Fourteen downloadable IDE products, resolved reliably

PhpStorm, RubyMine, DataGrip, RustRover, and MPS join the catalog — 14 IDE products, up from nine (#430, #434).

• Android Studio resolution picks the newest advertised version, with pinning by version, prefix, baseline, or channel (#432); JetBrains EAP resolution falls back to the newest available build when an EAP channel goes stale — ending the PyCharm "Build Expired" failure found in #412.
• Downloads retry stalled connections with resume, resuming from the partial file (#423); every catalog product is integration-tested against recorded feed payloads, with opt-in live-network lanes (#431).

devrig install: agents, the plugin, and any MCP client

• New devrig install plugin discovers running JetBrains IDEs and installs or updates MCP Steroid over each IDE's built-in REST endpoint — the IDE's own install dialog is the consent gate; --check is a read-only dry-run (#82, #391). devrig backend / devrig project listings promote the command for every running IDE lacking the plugin.
• New devrig install config prints the manual MCP configuration for clients devrig cannot configure automatically (Cursor, Windsurf, …); bare devrig install prints an overview with live per-agent CLI detection (#277); a missing agent CLI yields friendly guidance at exit 64 instead of a stacktrace (#342).
• Flag-less devrig install devrig does exactly one thing — re-register the launcher and PATH — with no implicit plugin installs, running under DEVRIG_JAVA_HOME, never touching your JAVA_HOME (#398). Agents are configured only through their own CLIs; docs/install-scripts-contract.md locks that scope in writing.

In-IDE onboarding and a devrig-first settings page

When devrig is missing, the plugin can show a single promotion balloon linking devrig.dev — behind a registry key that is off by default; the settings page carries the same offer as the default surface (#367). One click installs devrig through devrig's own updater machinery (shared per-pid markers prevent duplicate ~611 MB downloads), and installing devrig registers nothing with any agent.

The settings page is one Devrig section (Tools → Devrig — MCP Steroid, #394) plus a collapsed direct-HTTP section marked deprecated: a copyable install one-liner next to a button that runs the same script, display-only devrig install <agent> rows, and a collapsed stdio mcpServers snippet for other MCP clients. Every displayed path is the real absolute OS-native path. The Marketplace listing was rewritten around the core value (#355, #395).

devrig sessions that fail loudly, with bounded process waits

• devrig mcp self-terminates when orphaned — SIGKILL'd agent sessions no longer leave ~250 MB JVMs running for days (#132); every production process wait is bounded, and timed-out process trees are force-killed (#387).
• A malformed stdin line no longer wedges the MCP session: devrig answers with JSON-RPC -32700 and keeps serving (#461).
• Windows: the user-PATH registration hang is fixed (#150), and devrig status no longer reports false registration drift over an unquoted devrig.cmd path (#160).

Windows support, validated on real Windows

The devrig launcher, managed-backend commands, and the test infrastructure now work on Windows dev hosts (#158); :test-integration-agent-launch runs the same agent-launch matrix on Windows and Linux with per-OS assertions (#255, #257, #262, #269). The suites stay genuinely Windows-correct — CRLF-normalized assertions, Path.of(...)-built path fragments, an injectable executability probe (#445) — and the agent CLI test runner bounds whole process trees and cleans up under NTFS lock semantics (#407).

Install scripts: correct next steps, session PATH, honest naming

The installer build and verification model — every URL and SHA-256 baked in at build time, per-platform JDKs, PGP-verified vendor feeds — is on the blog: Install, Launch, Update: Shipping a CLI on Five Platforms — the devrig Approach.

• The printed next step is agent-qualified (devrig install claude|codex|gemini) (#320), and install.ps1 prepends the bin dir to the current session's PATH (#275).
• install.ps1 works on stock Windows PowerShell 5.1 — StrictMode-safe arch detection (#273), no progress-bar download crawl (#274).
• Both installers are contractually non-interactive under curl|sh / irm|iex with ASCII-only output (#278), and the JDK install directory is named by the vendor JDK version (#362).

Prompt corpus: recipes that work on every IDE

• The structured test-run article is available on every IDE (#406): the Gradle recipe stays on IDEA/Android Studio while a platform-only branch covers PyCharm, GoLand, WebStorm, CLion, RubyMine, and DataGrip — and pre-existing runs of the same configuration are never misattributed or destroyed.
• The lsp/completion recipe compiles warning-free on 2026.1 and 2026.2 via the public extension point (#409), and verification primitives now distinguish "clean" from "did not run" with a canonical result vocabulary (#142).

devrig.dev everywhere, and a devrig-first website

https://devrig.dev is the single canonical public identity (#197, #319, #330, #335): loop-free redirects from the old host, corrected canonical/OG/sitemap metadata, protected by build-time assertions and post-deploy live checks (#331, #332).

• The homepage centers one primary action — install devrig — and the README follows with honest capability claims (#334, #337–#339, #349); a live-site audit fixed tool counts, commands, and lingering old-domain URLs (#348).
• The honest headless story: Xvfb on Linux/CI, a real GUI on macOS/Windows, no true headless — with a new "Running devrig in CI" guide (#343, #346, #219) — and a page of measured with/without-MCP A/B findings with test sources and CI run IDs as provenance, honest negatives included (#232).

Under the hood: build, CI, and shared internals

• Gradle 9.6.1 + IntelliJ Platform Gradle Plugin 2.18.1 with every resulting deprecation resolved (#371); a remote build cache with a read-only public token as the zero-setup contributor fallback; release builds compile entirely from source with all caches disabled.
• The #412 burn-down brought the CompatTests lane to 9/9 and unblocked full main-matrix runs (test design: A Real IntelliJ IDEA Inside Docker); installer integration tests dropped from ~10 minutes to 44 seconds via digest-pinned images (#443); Gemini missing-key tests report SKIPPED honestly (#408).
• A new IJ-free devrig-common module holds everything the CLI and the plugin share — the ~/.mcp-steroid layout, update coordination, launcher tooling, PID-marker wire types — with forbidden-import and CI guards keeping it minimal (#444).
• Design records land the validated LIST/CALL recipes for IntelliJ's native MCP tools (#352, #353) — groundwork for a future release.

Known issues

• #259 — devrig install plugin targets running IDEs only; closed-IDE installs are the recorded follow-up design.
• #267 — devcontainers: the client project root is not yet configurable.

Acknowledgements

0.102 is the first release of this project built by a real team — thank you to every contributor:

• Matvei Ludzskii (@matveidetonator) — the schema-driven devrig CLI unification (#284): generated tool commands, open_project --wait, output and exit-code hardening, and the Docker CLI smoke tests (81 commits, 8 merged PRs), plus nine issue reports including #414 and #415.
• Grigory Gulyuk (@BraindeadDogge) — the in-IDE devrig onboarding (#367): the state-driven settings page, display-only agent setup commands, and install-via-devrig's-updater (41 commits), plus 17 issue reports across the plugin UX/activation series (#222–#228, #242, #244–#249, #160, #201, #413).
• Yahor Berdnikau (@Tapchicoma) — the Kotlin Build Tools API migration (#361) behind this release's compile-speed story, contributed together with the Kotlin team: dropped the kotlinc-dist download and daemon, and structured the compiler messages (26 commits). Thank you for the collaboration and the ongoing support!
• Aleksei Priakhin (@aleksei-priakhin) — Windows dev-host adoption (#158): the devrig launcher plus the test and prompt-compilation infrastructure on Windows hosts, and a DaemonCodeAnalyzer deprecation fix.
• Serge Baranov (@CrazyCoder) — the kotlinc 2.4.10 bump for 2026.3 EAP (#359, fixing his own report #357), and the reports that drove much of this release's contract work: the execute_code framing break (#154), the missing host-IDE identity (#155), the Android Studio / Java 21 incompatibility (#157), and the UpdateChecker version-comparison hazards (#358, #360).
• Igor Engel (@gt22) — preserving the agent-produced patch for evaluation in the test-experiments arena (#256).
• Dmitriy Zharikhin (@dzharikhin) — reporting the devcontainers project-root configurability gap (#267).
• Eugene Petrenko (@jonnyzzz) — project lead: the devrig CLI, installer, and auto-update; plugin architecture; release engineering and CI (381 commits, 116 merged PRs).