ssh

plugin-ssh — Served by	plugin-ssh
plugin-ssh — Placement	compiled-in (in-process)
plugin-ssh — Version	2026.209.0000
plugin-ssh — Served by	plugin-ssh
plugin-ssh — Placement	compiled-in (in-process)
plugin-ssh — Version	2026.209.0000

ssh is a command word served by 2 plugin candies — plugin-ssh and plugin-ssh — at different points in the command tree. Both are real invocations; charly --help prints which is which.

About plugin-ssh, which serves it

COMPILED-IN charly COMMAND-class plugin owning the externalized charly ssh tunnel spice/vnc command (#118 loader+check-tail cone). It opens an SSH-forwarded local SPICE/VNC endpoint pointing at a VM’s display on a remote libvirt host, for clients that don’t natively understand qemu+ssh:// (standalone remote-viewer with a TCP addr, TigerVNC, Spicy). virt-manager and remote-viewer --connect qemu+ssh://… do NOT need it.

The plugin owns the command end to end: the kong grammar (SshCmd → tunnel spice/vnc), the sshx SSH-tunnel machinery, the vmshared libvirt-URI parse, and the kit UNIX→TCP bridge — all sdk libraries. The ONE thing it cannot do itself is the display-endpoint RESOLVE (go-libvirt, out-of-process): it reaches verb:libvirt DIRECTLY over its in-proc reverse channel via InvokeProvider, so no charly-core symbol crosses the boundary.

ssh is COMPILED-IN (listed in charly/charly.yml compiled_plugins) BECAUSE its Invoke(OpRun) needs the in-proc reverse channel — threaded by dispatchInProcCommand — to reach verb:libvirt. The out-of-process CliMain path has no reverse channel, so it errors. command:ssh dispatches through the compiled-in registry path (registerCompiledPlugin → resolve(ClassCommand,“ssh”) → dispatchInProcCommand → Invoke(OpRun)); NewMeta advertises command:ssh with no plugin_input (the args are plain CLI tokens kong-parsed into SshCmd).

About plugin-ssh, which serves it

COMPILED-IN charly COMMAND-class plugin owning the externalized charly ssh tunnel spice/vnc command (#118 loader+check-tail cone). It opens an SSH-forwarded local SPICE/VNC endpoint pointing at a VM’s display on a remote libvirt host, for clients that don’t natively understand qemu+ssh:// (standalone remote-viewer with a TCP addr, TigerVNC, Spicy). virt-manager and remote-viewer --connect qemu+ssh://… do NOT need it.

The plugin owns the command end to end: the kong grammar (SshCmd → tunnel spice/vnc), the sshx SSH-tunnel machinery, the vmshared libvirt-URI parse, and the kit UNIX→TCP bridge — all sdk libraries. The ONE thing it cannot do itself is the display-endpoint RESOLVE (go-libvirt, out-of-process): it reaches verb:libvirt DIRECTLY over its in-proc reverse channel via InvokeProvider, so no charly-core symbol crosses the boundary.

ssh is COMPILED-IN (listed in charly/charly.yml compiled_plugins) BECAUSE its Invoke(OpRun) needs the in-proc reverse channel — threaded by dispatchInProcCommand — to reach verb:libvirt. The out-of-process CliMain path has no reverse channel, so it errors. command:ssh dispatches through the compiled-in registry path (registerCompiledPlugin → resolve(ClassCommand,“ssh”) → dispatchInProcCommand → Invoke(OpRun)); NewMeta advertises command:ssh with no plugin_input (the args are plain CLI tokens kong-parsed into SshCmd).

charly --help prints the command tree, including where each ssh is invoked and under which parent.