Junction: a VS Code chat sidebar that bridges seven local agent runtimes over three different plumbing shapes

Seven backends, three plumbing shapes and one unified interface

The claim on the tin is one unified interface over multiple agent runtimes, and the per-backend notes are where that gets tested. Read them in order and the seven integrations fall into three shapes. OpenClaw connects over a WebSocket gateway with session and model management. Hermes gets native dashboard support over both a WebSocket and a REST API. Souveraine is an HTTP server integration with managed runtime spawning, and MiMoCode is a server connection that is either auto-spawned or pre-configured. Then four are not servers at all: Goose needs a data directory and a secret key, OpenCode needs a binary path and a config home, OpenHands needs a server launcher and a home directory. So three of the seven are socket or HTTP integrations you have to have running, and four are configuration lookups that tell the extension where an existing runtime lives. The follow-up behaviour is configurable globally or per-bridge, which confirms that bridges are first-class objects in the code rather than seven copies of the same adapter.

The exit animation list has eleven entries and the sentence above it says nine

The splash screen is the most developed part of this extension by a wide margin, and it contains the repository's only arithmetic error. The text says the wordmark exits through one of 9 animation modes, then lists eleven. They are spiral out with a configurable radius and length, spiral in converging to a tightening spiral, an explode with gravity, a second physics-based explosion with bouncing off edges and per-axis momentum, float away with direction-based tilt, a horizontal flatten that crushes the letters to a single pixel line with a configurable hold time, a weaker explode, a crawl converging on a vanishing point with a target vertical position, a pixel shatter with per-axis momentum, a mode where the rain physically pushes the letters off screen, and a random selector that picks a different one each time. Several of those modes have three to five control sliders each. Finding this is not a criticism of quality, since everything else in the document is precise; it is a reminder that the animation engine is where the attention went, and that the count in the prose is maintained by hand while the list is maintained by building modes.

A settings panel with three tabs, one of them for something nobody documents

The animation settings are reached from a gear icon in the chat header and the panel is described in the most concrete terms anywhere in the readme. It has three tabs named Chat, Bobber and Splash. The Splash tab contains two collapsible accordions for appearance and motion, a dropdown of exit modes with its own per-mode sliders, and a live preview canvas you can click on to test animations. The panel is fully draggable and resizable with no height limit, which is the sort of detail that only gets written when someone has spent time in it. The gap is the Bobber tab. It is named in a list of three and then never mentioned again, and nothing in the document explains what a bobber is, where it appears, or what settings it holds. The rain itself is documented exhaustively in comparison: ten character sets from Katakana through Hangul, emoji and binary to a custom option, direction, reverse chance, bouncing off the edges, gravity and speed, and an emoji rarity expressed as one in N where the documented range runs from 1 for all emoji to a million for one in a million.

The licence carries two copyright holders because the socket layer is borrowed

The credits section is short and unusually precise about what is and is not original. Junction is based on an existing extension by another author, and the WebSocket and gateway plumbing traces back to that project. The multi-bridge architecture, the modular webview UI, the animation engine and the model and session managers are described as original to Junction. The licence line then names both: an MIT licence with copyright for the original project and copyright for Junction's author. That is the correct way to handle a derived codebase, and it is also useful information for anyone reading the code, because it tells you which parts to treat as inherited and which to read as this author's decisions. For an extension whose whole job is translating between an editor and someone else's agent runtime, the gateway layer being inherited is unsurprising. What is more interesting is that the reusable part, the abstraction over seven differently-shaped backends, is listed as the original contribution, since that is the part a fork would most want.

Installing from source means a shell script and a window reload

The install path has two commands and a manual step:

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

The requirements are a specific version floor, VS Code 1.120 or higher, and a local agent runtime already running, with three examples given of what that means in practice. The manifest matches the floor with a caret range on the editor engine and marks the package as a preview build, which is the honest signal for something at version 0.1.1. Four scripts sit at the repository root and only one is named in the readme: the install script that wraps the build, a build script, a quickstart script and the compile-and-install wrapper. Nothing says which of the others a contributor should run or in what order, which is a small friction point for anyone wanting to work on it rather than use it. The extension registers itself as a container in the secondary sidebar with a single webview inside it, and it activates on startup finished rather than on a command, so it is running before you open it.

Twenty-one translation files for a single sidebar, and one tagged release

Two numbers in this repository do not sit comfortably together. The first is localisation: twenty-one translation files at the root plus a localisation directory, covering Arabic, Bulgarian, Czech, German, English, Spanish, French, Hindi, Hungarian, Italian, Japanese, Korean, Dutch, Polish, Brazilian Portuguese, Russian, Swedish, Turkish, Ukrainian, Simplified Chinese and Traditional Chinese. That is more languages than most products this size ever ship, and it is not a trivial commitment for a single chat sidebar with an animation engine. The second is the release record: one tag, version 0.1.1, published on 2026-06-29, and the last commit is dated the same day. So as of the material collected here there have been no commits in the three months since, on a repository with 581 stars, 9 forks and no open issues at all. Zero open issues on a project this young is either a sign of a smooth experience or a sign that nobody is filing anything, and the localisation surface suggests the first while the release history suggests a very early stage overall.

Two layouts fight over the same problem in opposite directions

The chat surface gets one short feature list, and the one interesting decision in it is that there are two layouts solving the same problem in opposite directions. Compact mode folds activity into summary accordions, which gives a dense view where reasoning is one click away and the default state of a thread is its conclusion. Timeline mode shows a chronological activity rail with dot indicators, reasoning disclosure and an orange accent theme, with sticky user prompts, which gives a record of how the agent got there rather than only where it ended up. Both adapt to whatever colour theme the editor is using. Around that sit three features that matter more for agent work than the layout does. Workspace context lets you drag files into the input or right-click a file or selection to add it to the current thread, which is the difference between an agent that knows about your repository and one that does not. Per-session model and reasoning effort selection from the sidebar header, so two threads can run different models. And three follow-up modes, which is where agent UX usually breaks.

Queue, steer or interrupt, and the choice is per-bridge

The follow-up feature is the one to understand before you install, because it decides how the sidebar feels while an agent is mid-turn. There are three behaviours: queue a message for when the agent finishes, steer mid-turn without stopping, or interrupt and redirect. Queueing is the safe default, since it means you can write the next instruction while the current one runs and it applies afterwards. Steering is the interesting one, because it requires the runtime to accept input while generating, which is a protocol capability rather than a UI feature. Interrupting and redirecting is the most useful and the most dangerous, since a half-executed tool call may not be safely resumable. That the choice is configurable globally or per-bridge is the detail worth sitting with: it implies the seven backends do not all support all three behaviours, and that the extension exposes the difference rather than hiding it. The readme does not say which backends support which mode, so anyone relying on steering with a specific runtime has to find out by trying.

Editorial conclusion

Junction is useful precisely because it assumes you already run an agent on your own machine and does not try to replace it. Nothing leaves the machine that your existing runtime was not already leaving, the extension contributes one webview to the secondary sidebar, and the per-backend configuration is short enough to set up in a minute once you know which of the three plumbing shapes your runtime uses. Two things to weigh. The feature budget is visibly uneven, since the animation settings panel gets three tabs, per-mode sliders and a clickable preview canvas while the chat surface itself gets a paragraph, and one of those tabs is for something the documentation never explains. And the project is young in a way that the star count hides: one tagged release, published on the same day as the last commit, three months of silence since, and a licence that carries two copyright holders because the socket layer came from another project. Before you adopt it, confirm three things: which of the seven backends your runtime matches and whether it is a socket, an HTTP server or a config lookup, whether the per-bridge follow-up settings work the way your workflow expects, and whether VS Code 1.120 or newer is acceptable for your team, since that floor is what gates the whole extension.

Frequently asked questions

Official sources

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