Plaer1/junction: a VS Code chat sidebar for local AI coding agents

The gap Junction fills: one sidebar, seven local agent runtimes

Local coding agents tend to ship their own front ends. OpenClaw exposes a WebSocket gateway, Hermes serves a dashboard over WebSocket and REST, Souveraine runs an HTTP server, and Goose, OpenCode, OpenHands and MiMoCode each expect their own configuration and launch path. If you switch between two of them, you switch tools, and your editor stops being the place where the conversation happens. Junction's answer is a single VS Code webview registered in the secondary sidebar, with a bridge layer behind it that speaks to each runtime. The target user is an engineer who already has one of these runtimes on the same machine and wants file context from the workspace to travel with the prompt. The README lists the seven backends by name and gives one line of mechanism for each: WebSocket gateway with session and model management for OpenClaw, native dashboard WebSocket plus REST for Hermes, HTTP server with managed runtime spawning for Souveraine, auto-spawned or pre-configured server connection for MiMoCode, data directory and secret key for Goose, binary path and config home for OpenCode, and a server launcher with home directory for OpenHands. That list is the whole pitch, and it is a reasonable one, because the alternative for most people is a browser tab per agent.

How the bridge layer, webview and session managers fit together

The repository layout tells you most of the architecture. src/ holds the extension host code and a modular webview UI, and package.json declares a single webview view with id junction.chatView inside a view container with id junction-explorer, mounted in the secondarySidebar. The extension activates on onStartupFinished and the main entry is ./dist/extension.js, so the TypeScript in src/ is compiled by build.js rather than loaded directly. Commands are namespaced under junction: junction.configureRuntime, junction.openChat, junction.showLogs and junction.addToThread, which maps to the four things a user does: point the extension at a backend, open the panel, read the logs when a bridge fails, and push a file into the current thread. The README credits openclaw_vscode by Owen-Liuyuxuan for the WebSocket and gateway plumbing, and states that the multi-bridge architecture, modular webview UI, animation engine, and model and session managers are original to Junction. That split matters when you read the code: the transport layer has a prior life, the abstraction over seven runtimes does not. Model and reasoning effort are selectable per session from the sidebar header, which implies session state is held per thread rather than globally. The README does not document where that state is persisted or what happens to an in-flight session when the extension host reloads.

Installing Junction from source and opening the sidebar

The README gives source installation only. There is no marketplace listing documented, and the extension is marked "preview": true in package.json. Clone the repository, then run the two commands the README shows. npm install pulls the dependencies declared in package.json, and ./compile-and-install.sh builds the extension and installs it into your local VS Code. The repository also contains install.sh and quickstart.sh at the top level, but the README does not describe what either does, so treat the documented pair as the supported path.

npm install
./compile-and-install.sh
# Then: Ctrl+Shift+P → Developer: Reload Window

After the reload, the README says to open the panel from the Command Palette with Junction: Open Sidebar. The view container is junction-explorer and the webview is junction.chatView, so if the sidebar appears empty, that is the pair to check in the extension host logs, which Junction exposes through the Junction: Show Logs command. The declared engine floor is VS Code 1.120.0 or higher, and an older build will refuse to activate the extension rather than degrade. You also need a runtime actually listening: the README names OpenClaw Gateway, the Hermes dashboard and the Souveraine server as examples. Once connected, the workflow the README describes is drag and drop a file into the chat input, or right-click a file or selection and add it to the current thread, then send. Assistant responses, tool call cards, reasoning blocks and diffs render inline with syntax highlighting, so a diff arrives as a diff rather than as text you have to read around.

Where Junction is thin: per-backend setup and the preview label

The README names seven backends and gives each one line. It does not give a configuration table. For Goose you are told the bridge needs a data directory and a secret key; for OpenCode, a binary path and a config home; for OpenHands, a server launcher and a home directory. What those keys are called, where they are stored, and what a valid value looks like is not in the README. The configureRuntime command exists, so the settings are presumably collected through the UI, but the repository documentation does not describe the fields. That is the practical cost of a seven-backend design: the surface is wide, and the documentation depth per backend is one sentence. The second constraint is the preview flag. Version 0.1.1 is the only release listed, published on 2026-06-29, and package.json sets "preview": true. The last push to the repository was on 2026-06-29, which is close to three months before today's date, so there is no basis for calling this actively developed. The README also does not document rollback, migration between versions, or what happens when a bridge protocol changes underneath the extension. If your runtime updates its gateway API, you are reading the logs and waiting.

The animation engine is the most documented part, and that is a signal

Count the README sections. Installation gets two code blocks and a requirements list. The splash screen and animations get the longest section in the document, with 10 character sets, rain direction and reverse chance, bounce sides, gravity and collision controls, an emoji rarity expressed as 1/N where 1 means all emoji and 1000000 means one in a million, and 11 exit modes from spiral out to rain push, each with its own sliders and a live preview canvas you can click. The animation settings panel has three tabs, Chat, Bobber and Splash, and is draggable and resizable with no height limit. This is genuinely unusual work, and the matrix-style rain behind the wordmark is clearly a labour of love. It is also a tell. A project that documents its splash exit modes more thoroughly than its bridge configuration is telling you where the author's attention went. For an evaluation, that means the animation layer is the part you can trust to behave as described, and the agent integration is the part you should test against your own runtime before you rely on it for a working day.

Junction against openclaw_vscode and against the built-in chat panel

The honest comparison is with the project Junction is based on. openclaw_vscode by Owen-Liuyuxuan is MIT-licensed and, per the README, supplies the WebSocket and gateway plumbing Junction still uses. If you run OpenClaw and nothing else, the upstream project is the narrower and more predictable choice: one backend means one configuration path and one failure mode. Junction's difference is the abstraction layer, and you only pay for it if you actually run more than one runtime or expect to. The other alternative is not an extension at all: each of these runtimes already ships a front end, whether that is the Hermes dashboard, the Souveraine HTTP server, or a terminal session for Goose and OpenCode. Those front ends do not have your workspace files one drag away, which is Junction's real argument for existing. It is a context-transfer argument, not a capability argument, and it is worth being clear about that before installing.

Licence, maintenance and what an upgrade costs you

Junction is MIT-licensed, with copyright attributed in the README to both Owen-Liuyuxuan for the original openclaw_vscode and Plaer1 for Junction. MIT is permissive: you can fork, modify and redistribute, provided the copyright notice and permission notice travel with the code. The repository carries a LICENSE file at the top level, which is the text to read rather than this summary, and nothing here is legal advice. The practical licence question for a team is different: because the extension is installed from source rather than published, your upgrade path is git pull plus a rebuild, and you own the build. The compile-and-install.sh script is the boundary between the repository and your editor. There is no documented release channel, no changelog entry beyond CHANGELOG.md in the repository root, and one tagged version. Budget for reading the diff yourself before each rebuild, and expect the l10n and package.nls.*.json files in the root to change often, since the extension ships localised strings for more than twenty locales while the README is English only.

Editorial conclusion

Adopt Junction if you already run one of the seven supported local agent runtimes and want the conversation inside VS Code's secondary sidebar instead of a terminal or browser tab, and if you are comfortable with a 0.1.1 preview where the README documents the animation engine in far more detail than the bridge configuration. Do not adopt it if you need a hosted model, a documented per-backend setup table, or a stable release; nothing in the repository suggests either exists yet. Verify first that your runtime is one of OpenClaw, Hermes, Souveraine, MiMoCode, Goose, OpenCode or OpenHands, and that your VS Code version is at least 1.120.0, since the extension declares that engine floor in package.json.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Plaer1/junction on GitHub
4. README
5. Releases