Skip to content
OpenCharly

dsh-cli

Recipe card from the charly-tools plugin (Images — the deployable catalog).

dsh-cli

Section titled “dsh-cli”

The compiled-in charly dsh management CLI for a deployed deepseek-harness (dsh) box — a command:dsh plugin. It reaches a DEPLOYED box over the reverse channel via the plugin-cmd pattern (the “pod-lifecycle” host-builder’s op=“cmd”), so it requires COMPILED-IN placement. Use it to inspect a running dsh deployment: the dsh version, the web UI health, the profiles under $DSH_HOME/profiles, and a profile’s plugins.

Command tree

Section titled “Command tree”
  • charly dsh status --box <name> [--instance <name>] — dsh version + web UI health in the box (the web UI probe reads the launch token from $DSH_HOME/web-token).
  • charly dsh profile list --box <name> [--instance <name>] — profiles under $DSH_HOME/profiles.
  • charly dsh plugin list --box <name> [--instance <name>] --profile <name> — a profile’s plugins (default profile: web).

Every leaf takes --box <name> (required) + --instance. The command’s stdout rides the host-held interactive leg straight to the operator’s terminal; a non-zero exit in the box propagates as the command’s own exit code.

The dsh: check verb

Section titled “The dsh: check verb”

The plugin ALSO serves the declarative dsh: check verb — the in-box probe counterpart of the CLI, authored as a check: step in a candy/box plan. It is IN-BOX (the one place plugin-dsh diverges from plugin-agentteams’ host-based cc.ResolveEndpoint): the provider runs dsh commands INSIDE the venue via cc.Exec() (cc.Exec() works under both box and live modes — the built image carries the dsh binary + $DSH_HOME layout). Methods:

  • dsh: version — dsh --version in the venue (build + deploy context).
  • dsh: web-running — read the launch token from $DSH_HOME/web-token (persisted there by the dsh candy’s entrypoint on service start), exchange it on http://127.0.0.1:3080/?token=<token>, then exercise an /api/* call with the resulting cookie. dsh web authenticates at TWO layers: the launch token (a tokenless GET / returns 401) AND a Host/Origin browser-trust fence every /api/* call passes before authentication. The probe asserts both, so it proves the app’s API surface actually answers and not merely that / responds. A reverse-proxy deployment must additionally start dsh web --trusted-host <host:port> — a host-side requirement this IN-BOX probe (always dialing 127.0.0.1) cannot itself observe. A missing token file fails the probe with a clear error rather than a silent tokenless probe. Deploy context; skips under charly check box — no running service on a disposable podman run --rm.
  • dsh: profile-list — list profiles under $DSH_HOME/profiles (build + deploy context).
  • dsh: plugin-list — list plugins for a profile (profile: <name>, default web) via dsh plugin --profile <name> list (build + deploy context).

The verb’s method + method-exclusive modifiers ride the desugared plugin input, validated at runtime against the served #DshInput schema.

Example

Section titled “Example”
charly dsh status --box my-dsh-box
charly dsh profile list --box my-dsh-box
charly dsh plugin list --box my-dsh-box --profile web

Cross-References

Section titled “Cross-References”