Crush vs Droid CLI

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.

Droid CLI

droid exec is read-only unless --auto raises the autonomy level, with command rules, an optional kernel-enforced sandbox, JSON output and documented exit codes. No free tier, status page or security.txt was found, the source is closed, and usage metrics go to Factory by default.

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

Droid CLI

1. Set FACTORY_API_KEY (starts fk-) from the API keys page in Factory settings for headless runs. Interactive use signs in through a browser
2. Start with droid exec and no flags for analysis. Add --auto low for edits and --auto medium for installs, tests and local commits
3. Use --output-format json and read is_error, num_turns and session_id. Treat a non-zero exit code as failure
4. Set sandbox.enabled to true before running on untrusted code. In droid exec a sandbox violation is denied without a prompt
5. Pin the version in CI with npm install -g droid@<version>, or set FACTORY_DROID_AUTO_UPDATE_ENABLED=false on standalone installs, which update themselves