Droid CLI vs OpenCode

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.

OpenCode

Runs with no key or account on free OpenCode Zen models. Most permissions default to allow, and SECURITY.md says the permission system is not a sandbox.

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

OpenCode

1. Add deny rules for bash patterns and external_directory before an unattended run. Most tools default to allow
2. Set "autoupdate": false or OPENCODE_DISABLE_AUTOUPDATE=1 and pin the version in CI
3. Configure a provider key. With none, prompts go to free Zen models that may train on them
4. Set OPENCODE_SERVER_PASSWORD before opencode serve. Without it the server runs unauthenticated
5. Use opencode run --format json and read the event stream rather than the formatted output