VS Code / IDE extension for zero-friction adoption

[SebTardif]

Summary

Most AI coding agents run inside editors (VS Code, Cursor, Windsurf). A VS Code extension would dramatically reduce adoption friction by handling installation, MCP configuration, and project setup automatically.

This issue is the umbrella tracker for the official Patchloom VS Code extension in the dedicated patchloom-vscode repository.

Repo direction

• Repository: patchloom/patchloom-vscode
• Display name: Patchloom
• Manifest name: patchloom
• Preferred extension id: patchloom.patchloom

Delivery tracks

Foundation

• Scaffold extension packaging and local dev workflow #3 Scaffold extension packaging and local dev workflow
• Add automated test harness for the VS Code extension #11 Add automated test harness for the VS Code extension
• Define extension and CLI compatibility policy with upgrade diagnostics #7 Define extension and CLI compatibility policy with upgrade diagnostics

MVP editor setup

• Implement Patchloom binary discovery and status reporting #5 Implement Patchloom binary discovery and status reporting
• Add Initialize Project command for AGENTS.md bootstrap #6 Add Initialize Project command for AGENTS.md bootstrap
• Add MCP config injection for VS Code compatible editors #4 Add MCP config injection for VS Code compatible editors
• Add guided setup and richer Patchloom status UX #12 Add guided setup and richer Patchloom status UX

Post-MVP product capabilities

• Add diff preview and quick actions for common Patchloom workflows #8 Add diff preview and quick actions for common Patchloom workflows
• Support multi-root, remote, devcontainer, and WSL environments #14 Support multi-root, remote, devcontainer, and WSL environments

Managed install and zero-friction onboarding

• Implement managed Patchloom binary install, update, and reinstall flows #9 Implement managed Patchloom binary install, update, and reinstall flows
• Verify downloaded Patchloom binaries with checksums and safe install policy #10 Verify downloaded Patchloom binaries with checksums and safe install policy

Release and go-to-market

• Publish the extension to Marketplace and Open VSX #2 Publish the extension to Marketplace and Open VSX
• Prepare marketplace assets, branding, and support documentation #13 Prepare marketplace assets, branding, and support documentation

Binary management model

The extension should stay a thin wrapper around the Patchloom CLI, not a reimplementation of Patchloom in TypeScript.

Recommended binary resolution order:

1. explicit setting like patchloom.path
2. existing local install found on PATH
3. managed download from Patchloom GitHub Releases

Dependency split

Can be built now

• local binary detection on PATH
• explicit patchloom.path setting
• Patchloom: Initialize Project
• MCP config injection
• workspace status and health checks
• .vsix packaging and local dogfooding
• automated test harness and compatibility checks

Still depends on patchloom/patchloom#344

• managed binary download from public Patchloom releases
• public zero-friction onboarding for users who do not already have Patchloom installed
• polished marketplace launch tied to the public Patchloom release story

Effort estimate

Medium-large for the local-binary-first MVP. Full zero-friction onboarding, remote-environment support, and public distribution are a larger multi-phase effort. The backlog above is intended to capture the complete extension roadmap, not just the first release slice.

[SebTardif]

Re-checked during the improvement gate. This remains blocked on the public release work in patchloom/patchloom#344. Shipping an IDE extension depends on stable release artifacts, binary installation paths, and a public adoption surface.

Keeping this open as a post-launch enhancement.

[SebTardif]

This stays blocked on patchloom/patchloom#344, but adding concrete design notes now should make the eventual implementation much less fuzzy.

Proposed extension identity

• Display name: Patchloom
• Manifest name: patchloom
• Publisher / extension id: ideally patchloom.patchloom if the patchloom publisher namespace is available on both registries. If not, keep the manifest name as patchloom and use the chosen publisher namespace.
• Repo location for MVP: keep it in this repo under extensions/vscode/
• Split later only if needed: if the extension grows its own release cadence, issue volume, or maintainer set, move it to a dedicated patchloom-vscode repo later.

How it should be published

Patchloom should publish to both of the common VS Code extension registries:

1. VS Code Marketplace for standard VS Code users
2. Open VSX for VSCodium and other Open VSX based editors

Suggested packaging / publish flow:

• Build the extension as a .vsix
• Publish to the Microsoft marketplace with @vscode/vsce (vsce package, vsce publish)
• Publish the same artifact to Open VSX with ovsx publish
• Attach the .vsix to the GitHub release so users can also install it manually

That gives us the normal install path for VS Code, coverage for Open VSX based editors, and a manual fallback.

Binary management model

The extension should stay a thin wrapper around the Patchloom CLI, not a reimplementation of Patchloom in TypeScript.

Recommended binary resolution order:

1. Explicit setting like patchloom.path
2. Existing local install found on PATH
3. Managed download from Patchloom GitHub Releases into extension storage

That gives power users control, respects existing installs, and still provides zero-friction onboarding for new users.

Useful companion commands/settings:

• Patchloom: Install or Update Binary
• Patchloom: Reinstall Binary
• Patchloom: Initialize Project
• status indicator showing which binary is active and whether MCP is configured
• a setting to opt out of managed downloads and require a local binary

Prior art from similar extensions

Two patterns seem especially relevant:

rust-analyzer

The rust-analyzer extension keeps the real engine in the Rust binary, not in the extension code. The extension can download the matching server binary from GitHub Releases and also supports overriding the server path manually.

Takeaway for Patchloom: downloading the correct release artifact and allowing an explicit path override is a proven model.

Ruff

The Ruff extension prefers an environment-installed binary first and falls back to a bundled / managed one. That makes the extension friendly both to beginners and to users who already manage their own toolchain.

Takeaway for Patchloom: prefer a user-provided or already-installed binary when present, but provide a managed download path for zero-friction setup.

Suggested MVP scope

For a first release, I would keep the scope to:

• locate or install the Patchloom binary
• inject MCP config for VS Code compatible editors
• add Patchloom: Initialize Project
• show workspace status
• support reinstall / update of the managed binary

I would leave diff UI integration, transaction plan editor UX, and command-palette wrappers for common operations as follow-up issues after the install + configure path is solid.

[SebTardif]

Given the preference for a dedicated extension repository, I think we should treat that as the working direction for this issue.

Repo direction

• New repo: patchloom-vscode
• Why: keeps TypeScript, VS Code packaging, marketplace publishing, and extension-specific CI out of the Rust CLI repo
• What stays true: the extension should still be a thin client around the Patchloom binary, not a reimplementation of Patchloom in TypeScript

What can start now

A separate repo means we are not blocked from starting implementation work before Patchloom itself is public.

We can build the pre-launch MVP now:

• local binary detection on PATH
• explicit patchloom.path setting
• Patchloom: Initialize Project
• MCP config injection for supported editors
• workspace status / health checks
• .vsix packaging and local install for dogfooding

What is still blocked on patchloom/patchloom#344

What remains blocked is the public zero-friction onboarding story, not the repo creation itself.

Specifically, these parts still depend on patchloom/patchloom#344:

• managed binary download from public Patchloom releases
• normal public marketplace onboarding for users who do not already have Patchloom installed
• polished docs for the public install path

So I would split the work like this:

1. Start now in patchloom-vscode with local-binary-first workflows
2. After Ship v0.1.0 and go public patchloom#344 add managed download, public marketplace publishing, and the full one-click setup path

That keeps the issue moving now without pretending the public release dependency has disappeared.

[SebTardif]

Adding a concrete naming proposal so the future repo creation is less hand-wavy.

Proposed repo and extension identity

• GitHub repo: patchloom-vscode
• Repo description: VS Code extension for Patchloom. Installs, configures, and integrates the Patchloom CLI for editor-first workflows.
• VS Code display name: Patchloom
• Manifest name: patchloom
• Preferred publisher: patchloom
• Preferred extension id: patchloom.patchloom

If the patchloom publisher namespace is unavailable on one of the registries, keep the manifest name as patchloom and use the chosen publisher namespace there.

Why patchloom-vscode

• matches the common official-repo pattern used by projects like ruff-vscode and biome-vscode
• specific enough to be discoverable
• still accurate even if the extension also works in Cursor and other VS Code compatible editors

Suggested README opening

Patchloom for VS Code is the official editor extension for Patchloom. It helps you locate or install the Patchloom binary, configure MCP integration, initialize a workspace, and verify that the current project is ready for agent-driven Patchloom workflows.

Suggested package metadata

Keywords worth claiming early:

• patchloom
• mcp
• ai
• agent
• refactoring
• codemod
• json
• yaml
• markdown

Categories likely fit:

• Other
• Programming Languages
• Formatters

Initial repo breakdown

When we create patchloom-vscode, I would start with these top-level work items:

1. extension scaffold and local dev loop
2. binary discovery (patchloom.path, PATH lookup, status reporting)
3. Patchloom: Initialize Project command
4. MCP config injection for supported editors
5. status bar / health checks
6. .vsix packaging and pre-release dogfooding
7. later, after Ship v0.1.0 and go public patchloom#344, managed download + marketplace publishing

This should give the new repo a clear identity from day one, instead of creating it first and deciding the naming and packaging details afterward.