Cline vs Droid CLI

Cline

Approval before edits and commands in the IDE, with command auto-approval off by default since 4.0.0. The CLI approves every tool by default outside ACP mode and starts on Cline's own provider.

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.

Cline

1. Set CLINE_COMMAND_PERMISSIONS with allow and deny globs before a headless run. The CLI approves every tool by default
2. Pick a provider with -P and a key, or run cline auth. The default provider needs a Cline sign-in
3. Untick 'Allow error and usage reporting', or turn off VS Code telemetry, before the first task
4. Pin the CLI version. 2.3.0 was a malicious publish
5. Keep the hub on 127.0.0.1 or set ROOM_SECRET, and run 3.0.30 or later

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