Skip to main content
The CLI is not a lesser surface. It talks to the same daemon as the desktop app, so anything it does is real product behavior, not a debug path. Use it for automation, for scripting a repetitive setup, and for finding out what the app is actually doing when something looks wrong.

Two command families

The archcar namespace is the raw protocol surface. It has far more commands and reaches things the product verbs do not expose yet. When a guide reaches for archductor archcar something, that is why. Both follow the saved remote profile, so every command here works against a server-hosted daemon unchanged.

Environment

There is no “start the daemon” command, because you never need one: the client spawns archcar itself when it cannot reach a running daemon. Any archcar subcommand therefore doubles as a liveness check — inventory-snapshot is a cheap one. archductor archcar status and archductor archcar ensure are session commands, not daemon ones; they take a session id and a workspace respectively.

Repositories

Against a remote daemon use archductor archcar add-repository <path> instead — paths resolve on the daemon’s filesystem.

Workspaces

Sessions

Running and checking

Reviewing

Pull requests

Layouts

Service and remote

MCP and skills

History and import

Scripting notes

  • Most archcar commands print JSON-shaped responses, so jq works. The product verbs print human text.
  • Exit codes are meaningful. service setup in particular exits non-zero when the daemon did not come up, so provisioning scripts can trust it.
  • Set ARCHDUCTOR_ARCHCAR_REMOTE and ARCHDUCTOR_ARCHCAR_TOKEN in a CI job to target a daemon without writing a profile to disk. Environment wins over the saved profile.
  • archductor archcar stdio-proxy is what an ssh:// client runs on the far side. It is not something to invoke by hand.