plugin-cmd
| Placement | compiled-in (in-process) |
| Source | github.com/opencharly/charly/candy/plugin-cmd |
| Version | 2026.209.0000 |
| Candy | plugin-cmd |
This plugin is listed in charly/charly.yml’s compiled_plugins:, so its providers are compiled into the charly binary and register in-process.
Providers
Section titled “Providers”The reserved words this plugin serves:
cmd— command class
What it does
Section titled “What it does”COMPILED-IN charly COMMAND-class plugin owning the externalized charly cmd command
(#118 loader+check-tail cone) — run a single command in a running container with an
optional desktop notification on completion.
The plugin owns the command end to end: the kong grammar (CmdCmd), the container resolve
(deploykit.ResolveContainer / ResolveSidecarContainer), and –notify (the venue’s gdbus
session-bus call, driven directly on the deploykit.ContainerChain executor — a plugin
drives gdbus itself, the boundary law’s host-object-is-never-permanence rule). The ONE
thing it cannot do is the interactive exec, which is deploy-lifecycle machinery
(dispatchLifecycleTarget → OpAttach): it drives the hidden charly __cmd core reentry
over the generic HostBuild(“cli”) seam with INHERITED stdio, so the -i interactive
stream reaches the operator. The __cmd handler stays core (deploy-lifecycle-coupled
RESIDUE, gated on that coupling relocating), NOT a plugin — so no charly-core symbol
crosses the boundary; the plugin imports the sdk module alone.
cmd is COMPILED-IN (listed in charly/charly.yml compiled_plugins) BECAUSE its Invoke(OpRun) needs the in-proc reverse channel — threaded by dispatchInProcCommand — to drive HostBuild(“cli”). The out-of-process CliMain path has no reverse channel, so it errors. command:cmd is a FLAT command (Box + Command positionals), so NewMeta declares no Subcommands and ships no plugin_input.
See also the candy reference for this candy’s install surface.