Swttch

The deciding trait is how little it adds. Selected code goes over with a keystroke, changes come back in the diff viewer you already use to review other people's work, and files and the terminal open where they normally open. Nothing is reinvented, which means there is almost nothing to learn and almost nothing to go wrong in the layer itself.

What you are accepting is a single-vendor dependency wrapped in a thin plugin. Pick it for the one workflow it serves. Pick the broader panel if you want options later.

The convenience and the hole are the same feature. A tunnel exposes a session that can edit files and run commands to anyone who reaches the address, and a QR code is a credential printed on a screen in an office. Nothing in the listing describes authentication on that endpoint, an expiry, or what happens to the tunnel when the laptop sleeps and wakes somewhere else.

What it does right is the Windows story. PowerShell and WSL are both supported, which is more care than most plugins take with the platform they wish people were not using.

1. Deriving behaviour from the reference implementation is the correct way to build a compatibility layer, because it makes divergence the exception rather than the default and gives a user a documented expectation to compare against. 2. Stating what the plugin does not do is the harder kind of claim, since it is falsifiable and most vendors avoid it.

2. Neither statement is externally verified, and the second one is only as good as the source it is checked against, which anyone can read.

Single-vendor wrappers are the most fragile position in this category, and the author appears to know it, since a name that no longer contains the vendor's product is a decision made by someone planning for a second one. That is good judgement and it does not change the risk this year, which is that the thing being wrapped ships its own panel.

Moat: none. Likely path: obsoleted by a first-party plugin, or broadened fast enough to matter. Position: a free convenience, not a dependency, and copyleft terms make the fork obligation real.

Two things stop this being a memo. Strong copyleft on a tool that sits inside our development environment is a review my counsel will want to do properly, however unlikely the obligation turns out to be, and that review takes longer than the evaluation. The second is that the plugin is free and the thing it drives is not.

There is no console, no directory integration and no usage export, so I cannot report on it either. Approved with conditions: legal signs off on the licence first, and subscriptions are issued centrally rather than expensed.

Copyleft on a plugin means anyone who ships a modified version has to ship the source, and after a year of reading permissive licences being used to close things quietly, that is a choice I approve of. The source is small enough to read in a sitting and the prerequisites are honest: an IDE version, a Node version, an authenticated tool.

What I do not get is choice. The model belongs to whichever product the wrapped tool signs into, nothing serves from my hardware, and my own servers have no way in at this layer. Good licence, narrow road.