harness runtime management

Harness runtime management

Phase 9 W1–W4 · design: design-phase-9-harness-runtime.md

The platform manages the agent CLIs themselves — install, upgrade, pin, and provider wiring — through jobs executed by the daemon.

Install / upgrade / pin

Queued like any job; npm is the install channel (the one exception: claude update for an already-native claude-code). Versions are probed and reported back, the inventory card updates without a rescan, and installs merge DISABLE_AUTOUPDATER=1 so the CLI doesn't drift underneath the platform.

Provider config push (apply-config)

One provider spec per (machine, target), pointing at an LLM provider route + credential:

• The secret never rides the job — the daemon fetches the resolved {spec, secret} at execution time over a machine-PAT-only endpoint.
• Writers are merge-preserving and idempotent per target's native config: claude-code ~/.claude/settings.json, codex ~/.codex/config.toml + auth.json, deepseek's three slots (settings.yaml region, cordis.patch.yml acp override, ~/.dsh/.env), opencode ~/.config/opencode/opencode.json + a 0600 key file, pi ~/.pi/agent/models.json + settings.json + key file.
• Hand-managed sections are detected and refused untouched.
• The multi-model extras become the agent's switchable set (dsh catalog / claude allowlist / daemon-side picker rewrite).

Redacted config viewer

"View config" per agent reads the target's native config files live through the daemon, masks secret-bearing values daemon-side before upload, and shows them in a drawer with a count of what was hidden. Key files are redacted wholesale; ~/.dsh/.credentials.yaml is never read.