Crush vs DeepSeek Harness (dsh)

Crush

Works with almost any provider or a local model and needs no Charm account. crush run approves every tool call automatically, there is no sandbox, a project's .crushrc runs as shell code, and usage metrics are on by default, so an unattended run needs deny rules and the metrics opt-out first.

DeepSeek Harness (dsh)

Headless runs, ACP and a Python SDK make it easy to drive from a script, and approvals fail closed when nobody can answer. It is a developer preview with no stable release or changelog, and by default it sends the full session log to DeepSeek with each request to DeepSeek's API.

Crush

1. Add permissions deny rules or a PreToolUse hook before crush run. It approves every permission request in its session
2. Read .crushrc, crushrc and crush.json in a cloned repository before running Crush there. They execute as shell code at startup
3. Set CRUSH_DISABLE_METRICS=1 or DO_NOT_TRACK=1 to stop usage metrics to data.charm.land
4. Wrap crush run in your own timeout. It has no turn, time or cost limit flag
5. Configure a provider by environment variable or crushrc first. With none, crush run exits with an error asking for interactive setup

DeepSeek Harness (dsh)

1. Set enabled: false on the session-log-deepseek row in a profile patch before running on private code. Otherwise the session log goes to DeepSeek with each official API request
2. Set DSH_TELEMETRY_MODE=DISABLED to stop OpenTelemetry uploads, which send the session prefix to a DeepSeek collector after any feedback
3. Treat exit code 1 and the turn_end reason as failure. A --json stream can end with a final event for a failed run
4. Run in a disposable container or VM. The sandbox doesn't confine reads or network, and SAFETY.md says the project has had no security audit
5. Pin the version. npm latest (0.2.0-rc.2) and next (0.2.1-rc.2) differ, DeepSeek's changelog asks for 0.2.1-rc.1 or later, and the README warns of breaking changes