syncthing-clilisted

# Syncthing CLI (REST over SSH) Direct Syncthing management via the REST API, tunneled over SSH. No Syncthing MCP exists with sufficient trust score; this pattern is more reliable and auditable than a community plugin. ## Why CLI instead of MCP - Syncthing exposes a full REST API on `127.0.0.1:8384` by default (not exposed on the network interface). - All operations are achievable via `ssh <alias> curl` — no extra tooling, no credential surface beyond SSH. - Syncthing MCPs in community registries: low-star, single-maintainer. Trusting them with SSH access to a hub VM is a supply-chain risk. - Scripts are auditable, version-controlled, and idempotent by design. ## Setup ### Prerequisites - SSH alias `${WALTER_VM_SSH_ALIAS}` configured in `~/.ssh/config`. - Syncthing container running on the hub VM, API accessible at `http://127.0.0.1:8384` from the hub's localhost. - `jq` installed on the **operator's local machine** — the bootstrap script runs locally and pipes SSH stdout through `jq` to parse JSON responses. (`brew install jq` is already in `setup/Brewfile`.) - `curl` available on the hub VM (universal default; verify with `ssh "${WALTER_VM_SSH_ALIAS}" which curl`). - Syncthing API key stored in `~/.config/walter-os/secrets.env` as `SYNCTHING_API_KEY`. Never hardcode in scripts. ```bash # Verify SSH alias resolves ssh "${WALTER_VM_SSH_ALIAS}" echo ok # Verify Syncthing API is reachable from hub. # Header value contains a space ("X-API-Key: <key>"), so