Droid Exec is Factory’s headless execution mode designed for automation workflows. Unlike the interactive CLI,Documentation Index
Fetch the complete documentation index at: https://factory-changelog-may14.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
droid exec runs as a one-shot command that completes a task and exits, making it ideal for CI/CD pipelines, shell scripts, and batch processing.
Summary and goals
Droid Exec is a one-shot task runner designed to:- Produce readable logs, and structured artifacts when requested
- Enforce opt-in for mutations/command execution (secure-by-default)
- Fail fast on permission violations with clear errors
- Support simple composition for batch and parallel work
Non-Interactive
Single run execution that writes to stdout/stderr for CI/CD integration
Secure by Default
Read-only by default with explicit opt-in for mutations via autonomy levels
Composable
Designed for shell scripting, parallel execution, and pipeline integration
Clean Output
Structured output formats and artifacts for automated processing
Execution model
- Non-interactive single run that writes to stdout/stderr.
- Default is spec-mode: the agent is only allowed to execute read-only operations.
- Add
--autoto enable edits and commands; risk tiers gate what can run.
--model or --spec-model. For custom models, see Bring Your Own Key (BYOK).
Installation
Get Factory API Key
Generate your API key from the Factory Settings Page
Quickstart
- Direct prompt:
droid exec "analyze code quality"droid exec "fix the bug in src/main.js" --auto low
- From file:
droid exec -f prompt.md
- Pipe:
echo "summarize repo structure" | droid exec
- Session continuation:
droid exec --session-id <session-id> "continue with next steps"
Autonomy Levels
Droid exec uses a tiered autonomy system to control what operations the agent can perform. By default, it runs in read-only mode, requiring explicit flags to enable modifications.DEFAULT (no flags) - Read-only Mode
The safest mode for reviewing planned changes without execution:- ✅ Reading files or logs: cat, less, head, tail, systemctl status
- ✅ Display commands: echo, pwd
- ✅ Information gathering: whoami, date, uname, ps, top
- ✅ Git read operations: git status, git log, git diff
- ✅ Directory listing: ls, find (without -delete or -exec)
- ❌ No modifications to files or system
- Use case: Safe for reviewing what changes would be made
--auto low - Low-risk Operations
Enables basic file operations while blocking system changes:
- ✅ File creation/editing in project directories
- ❌ No system modifications or package installations
- Use case: Documentation updates, code formatting, adding comments
--auto medium - Development Operations
Operations that may have significant side effects, but these side effects are typically harmless and straightforward to recover from.
Adds common development tasks to low-risk operations:
- Installing packages from trusted sources: npm install, pip install (without sudo)
- Network requests to trusted endpoints: curl, wget to known APIs
- Git operations that modify local repositories: git commit, git checkout, git pull (but not git push)
- Building code with tools like make, npm run build, mvn compile
- ❌ No git push, sudo commands, or production changes
- Use case: Local development, testing, dependency management
--auto high - Production Operations
Commands that may have security implications such as data transfers between untrusted sources or execution of unknown code, or major side effects such as irreversible data loss or modifications of production systems/deployments.
- Running arbitrary/untrusted code: curl | bash, eval, executing downloaded scripts
- Exposing ports or modifying firewall rules that could allow external access
- Git push operations that modify remote repositories: git push, git push —force
- Irreversible actions to production deployments, database migrations, or other sensitive operations
- Commands that access or modify sensitive information like passwords or keys
- ❌ Still blocks: sudo rm -rf /, system-wide changes
- Use case: CI/CD pipelines, automated deployments
--skip-permissions-unsafe - Bypass All Checks
- ⚠️ Allows ALL operations without confirmation
- ⚠️ Can execute irreversible operations
- Cannot be combined with —auto flags
- Use case: Isolated environments
Fail-fast Behavior
If a requested action exceeds the current autonomy level, droid exec will:- Stop immediately with a clear error message
- Return a non-zero exit code
- Not perform any partial changes
Output formats and artifacts
Droid exec supports three output formats for different use cases:text (default)
Human-readable output for direct consumption or logs:json
Structured JSON output for parsing in scripts and automation:- Parse the result in a script
- Check success/failure programmatically
- Extract session IDs for continuation
- Process results in a pipeline
Build custom flows on raw JSON-RPC
For custom integrations, you can run Droid as a long-lived subprocess and drive the full JSON-RPC control surface over stdin/stdout:- Spawns
droid execwith the projectcwdand desired flags - Writes newline-delimited JSON-RPC requests with unique IDs
- Starts with
droid.initialize_sessionordroid.load_session - Sends turns with
droid.add_user_message - Reads stdout line-by-line and matches responses by
id - Handles
droid.session_notificationevents for assistant text deltas, tool events, token usage, errors, and turn completion - Responds to server-to-client requests such as
droid.request_permissionanddroid.ask_user - Calls other session methods to interrupt work, update settings, manage MCP servers/tools, inspect context, fork sessions, or compact history
- Implements timeouts, process cleanup, and session persistence
- Web, desktop, or IDE agent experiences with your own UX and controls
- Chat or copiloting surfaces that route user actions into Droid turns
- CI and workflow runners that execute Droid tasks and surface progress in build logs
- Orchestrators that queue work, resume sessions, fork conversations, and persist results
- Policy layers that approve, deny, transform, or audit tool permission requests
- Bridges from Droid events into your own protocol, message bus, telemetry, or storage layer
- TypeScript:
@factory/droid-sdkfor Node.js apps, streaming, multi-turn sessions, structured output, permissions, tool controls, and SDK-backed MCP tools - Python:
droid-sdkfor asyncio apps, streaming, direct client control, notifications, permissions, and typed event handling
Working directory
- Use
--cwdto scope execution:
- Use
-w, --worktree [name]to run the task inside an isolated git worktree on its own branch. This is useful for fanning out paralleldroid execjobs against the same repo without file conflicts:
Models and reasoning effort
Choose a model with-m and adjust reasoning with -r. See the Available Models for available models.
--use-spec to start in specification mode, where the agent plans before executing:
Tool controls
List available tools for a model:Custom models
You can configure custom models to use with droid exec by adding them to your~/.factory/settings.json file:
custom: prefix followed by the display name (with spaces replaced by dashes) and the index:
--model "custom:Kimi-K2-[Groq]-0"--model "custom:GPT-OSS-20B-[OpenRouter]-1"
customModels array (0-based).
Reasoning effort (
-r / --reasoning-effort) is not yet supported for custom models, but coming soon.Batch and parallel patterns
Shell loops (bounded concurrency):Unique usage examples
License header enforcer:Exit behavior
- 0: success
- Non-zero: failure (permission violation, tool error, unmet objective). Treat non-zero as failed in CI.
Best practices
- Favor
--auto low; keep mutations minimal and commit/push in scripted steps. - Avoid
--skip-permissions-unsafeunless fully sandboxed. - Ask the agent to emit artifacts your pipeline can verify.
- Use
--cwdto constrain scope in monorepos.
