v0.101

0.101

0.100 introduced devrig. 0.101 makes it the way you actually install and run MCP Steroid.
A single command now downloads devrig and a matching Java runtime, lays them out under your home
directory, and registers a stable launcher — so your agent can connect to an IDE you already have
open, or have devrig download, prepare, start, and stop a managed IDE backend for you.

devrig is the recommended entry point. Direct use of the MCP Steroid plugin's HTTP server is
still fully supported, but we recommend migrating to devrig: it owns installation, the Java
runtime, agent registration, and backend lifecycle, so there is far less to set up and keep in sync.

Independent project. MCP Steroid / Devrig is an independent open-source project. It is
not affiliated with, sponsored by, or endorsed by JetBrains.

One-command install

You no longer assemble devrig by hand. A generated bootstrap installer does it for you:

# macOS / Linux
curl -fsSL https://mcp-steroid.jonnyzzz.com/install.sh | sh

# Windows
irm https://mcp-steroid.jonnyzzz.com/install.ps1 | iex

The installer:

• Detects your platform (macos/linux/windows × arm64/x64) and downloads the matching
  devrig build and a Java 25 runtime — Amazon Corretto 25 on macOS, Linux, and Windows-x64;
  Azul Zulu 25 on Windows-arm64. You no longer have to install a JDK yourself.
• Bakes every URL and SHA-256 in at build time — there is no live discovery at install time
  (no GitHub API calls, no vendor lookups). Each download is SHA-256–verified before it is unpacked.
• Fails fast and clearly when a prerequisite is missing — it never installs system packages
  behind your back; it tells you exactly what to install and stops. musl/Alpine is detected and
  rejected up front (the IntelliJ IDEs require glibc).
• Hands off to devrig install devrig, so the binary registers its own stable launcher and PATH
  entry. The install script never writes the wrapper itself.

A predictable layout under ~/.mcp-steroid

devrig keeps everything under one fixed home so it is easy to inspect, back up, or remove:

~/.mcp-steroid/
├── bin/
│   └── devrig                       # stable launcher on your PATH (devrig owns + self-heals it)
└── binaries/
    ├── devrig-<os>-<cpu>-<version>-<sha12>/   # unpacked devrig dist, content-addressed
    └── jdk-<os>-<cpu>-<version>-<sha12>/      # the matching Java 25 runtime

• ~/.mcp-steroid/bin/devrig is owned by the binary, not the install script. Every devrig
  start re-checks the launcher, repairs it if it drifted, and makes sure ~/.mcp-steroid/bin is on
  your PATH (deduped to a single entry on Windows). Whatever you typed to launch it, you end up
  pointing at the one stable launcher.
• Binaries are content-addressed (<artifact>-<os>-<cpu>-<version>-<sha12>), so the same name
  can never collide between two different downloads, and re-installs are idempotent.
• The launcher pins the Java 25 it runs under (DEVRIG_JAVA_HOME), so devrig always runs on the
  runtime it shipped with regardless of your system Java.

devrig install is now smoother

• devrig install <claude | codex | gemini> is idempotent — re-running it upgrades an existing
  registration in place with step-by-step narration instead of failing or duplicating entries
  (#83,
  #84). It also reviews the agent's existing MCP
  servers and consolidates stray devrig entries down to one.
• devrig install <agent> --check is a read-only doctor: it reports whether the agent is
  registered correctly without changing anything (#86).
• devrig mcp is now the canonical stdio subcommand (the old devrig mpc stays as a hidden
  alias) (#85).

Smarter backends — start what's installed, list what's there

devrig now reasons about backends as four explicit groups — running-compatible,
running-incompatible, startable (installed but not running), and downloadable — and acts on them:

• steroid_open_project can start a stopped-but-installed backend for you. If the right IDE is
  installed but not running, devrig starts it, re-provisions the current plugin and VM options, and
  waits until it is reachable — no manual launch step.
• backend_name routing lets you target a specific backend explicitly when more than one is
  running (#87).
• list_projects / list_windows no longer mislabel the backend or duplicate their payload, and
  installed plugins are reported as a structured plugins[] section per backend
  (#88,
  #89,
  #90).
• project_name is now an opaque <name>-<hash> routing key so two projects that share a folder
  name route to the right place, instead of colliding
  (#92).

The cross-process identity behind all of this is the IDE install home recorded in each backend's
marker; a running IDE whose marker predates this (an older, incompatible plugin) is shown in an
"Other IDEs" group and is never offered as an open_project target.

A real settings page, devrig-first

The plugin's Tools → MCP Steroid settings page is back and reworked around agents and devrig
(#80,
#103). It leads with the devrig install
one-liners (copyable, per-OS), shows the actual server port rather than a hard-coded one, carries a
fit-to-paste JSON config block, and flags the legacy raw-HTTP path as the non-recommended option with
a link to the devrig docs.

steroid_execute_code quality-of-life

• The most-used PSI subpackages are imported by default in scripts, so common recipes need fewer
  import lines (#42).
• steroid_take_screenshot now reports coordinates in true pixel space, scaling the JFrame
  capture to the X display so steroid_input clicks land where you expect
  (#55).

Recipes & prompts

• The IDE recipe corpus is genuinely multi-IDE. A per-IDE coverage audit fixed articles (such as
  ide/inspect-and-fix) that were accidentally IntelliJ-only and didn't resolve in PyCharm and the
  other IDEs (#81,
  #98).
• A "refresh-then-find" idiom teaches scripts to pick up files created outside the IDE instead of
  missing them until a manual sync (#95).
• action-discovery documents that popup-style actions silently no-op from a headless
  DataContext, with the steroid_input click workaround
  (#62); recipes also warn against
  ActionGroup.getChildren(null) (#70).

Website & build infra

• Devrig-first website. The homepage and the release/installation pages now lead with the
  devrig install one-liner as the main content
  (#96,
  #97), with branded artwork and a polished
  bridge diagram. The live site now deploys from a long-lived website branch so install-script
  changes that depend on an as-yet-unreleased binary stay off the live site until the matching release
  exists.
• :installer-gen is a new build-tooling module that computes the JDK data model (latest Corretto
  25 / Azul Zulu 25, resolved live and OpenPGP-verified against pinned key fingerprints on every
  run) and generates the install.sh / install.ps1 scripts from it. Nothing is hand-pinned.
• :website-gen now generates version.json and updatePlugins.xml in Kotlin (Ktor), replacing
  the old Python/Make pipeline and matching the published XML byte-for-byte.
• Windows launcher uses a pathing JAR, fixing the "input line is too long" failure on Windows.
• The dead :jdk-downloader and :pgp-verifier modules were removed, and a compileAllClasses
  task + a GitHub "Compile Check" action now gate every merge.

Plugin Verifier

Verified against the primary target IntelliJ 2026.1 (261.22158.277): Compatible, 0 internal-API
usages (the hard release gate) and 6 experimental-API usages. Against the secondary EAP target
2026.2 (262.8117.19): Compatible, 5 experimental-API usages and 8 internal-API usages —
the two PluginManagerCore methods (getPlugin, getLoadedPlugins) that 2026.2 newly marks internal
and that have no public replacement available on both 2026.1 and 2026.2 (tracked upstream as
IJPL-246183), plus six ProgressModel members used
by the new window/background-task listing (IdeWindowsCollector), which 2026.2 also marks internal.
All are public on the shipping 261 target; they will be migrated before 2026.2 ships.

Known issues

• #78 — on a Windows-side IDE opening a
  WSL-hosted project, steroid_execute_code fails because the kotlinc spawn is routed into the WSL
  distro. Workaround: set the registry key mcp.steroid.storage.path to a native Windows path so
  the per-execution working directory leaves the \\wsl$ volume. A proper fix is in progress.

Acknowledgements

Thanks to @andrii0lomakin for the steroid_execute_code ergonomics
request that shipped here — default PSI imports (#42)
— and to @ivanpajic for reporting and patiently helping us chase down the
plugin install/discovery problems on recent IntelliJ builds
(#79).