Skip to main content
Droid Exec is Factory’s headless execution mode designed for automation workflows. Unlike the interactive CLI, 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 --auto to enable edits and commands; risk tiers gate what can run.
CLI help (excerpt):
Use any available model ID with --model or --spec-model. For custom models, see Bring Your Own Key (BYOK).

Installation

1

Install the Droid CLI

2

Get Factory API Key

Generate your API key from the Factory Settings Page
3

Set Environment Variable

Export your API key as an environment variable:

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

DANGEROUS: This mode allows ALL operations without confirmation. Only use in completely isolated environments like Docker containers or throwaway VMs.
  • ⚠️ 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:
  1. Stop immediately with a clear error message
  2. Return a non-zero exit code
  3. Not perform any partial changes
This ensures predictable behavior in automation scripts and CI/CD pipelines.

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:
Use JSON format when you need to:
  • 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:
This is the lowest-level integration path for building your own interaction model around Droid. Your process can send turns, stream assistant output, handle permissions, update settings, manage MCP/tools, interrupt work, and resume or fork sessions. Each stdin line is one JSON-RPC request. Each stdout line is a JSON-RPC response, server request, or notification. A custom client typically:
  • Spawns droid exec with the project cwd and desired flags
  • Writes newline-delimited JSON-RPC requests with unique IDs
  • Starts with droid.initialize_session or droid.load_session
  • Sends turns with droid.add_user_message
  • Reads stdout line-by-line and matches responses by id
  • Handles droid.session_notification events for assistant text deltas, tool events, token usage, errors, and turn completion
  • Responds to server-to-client requests such as droid.request_permission and droid.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
You can build on top of raw stdin/stdout to create custom interaction flows such as:
  • 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
For protocol reference and implementation patterns, see the low-level client and process transport in the TypeScript SDK. Prefer an SDK when possible:
  • TypeScript: @factory/droid-sdk for Node.js apps, streaming, multi-turn sessions, structured output, permissions, tool controls, and SDK-backed MCP tools
  • Python: droid-sdk for asyncio apps, streaming, direct client control, notifications, permissions, and typed event handling
For automated pipelines, you can also direct the agent to write specific artifacts:

Working directory

  • Use --cwd to 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 parallel droid exec jobs against the same repo without file conflicts:
Clean worktrees are auto-removed on exit; dirty ones are preserved so you can review and push the work.

Models and reasoning effort

Choose a model with -m and adjust reasoning with -r. See the Available Models for available models.
Use --use-spec to start in specification mode, where the agent plans before executing:
You can also use a different model for the spec phase:

Tool controls

List available tools for a model:
Enable or disable specific tools:

Custom models

You can configure custom models to use with droid exec by adding them to your ~/.factory/settings.json file:
To use a custom model, use the custom: prefix followed by the display name (with spaces replaced by dashes) and the index:
If you have multiple custom models configured:
You would reference them as:
  • --model "custom:Kimi-K2-[Groq]-0"
  • --model "custom:GPT-OSS-20B-[OpenRouter]-1"
The index corresponds to the position in the customModels array (0-based).
Reasoning effort (-r / --reasoning-effort) is not yet supported for custom models, but coming soon.

Sessions, tagging, and logs

Forking lets you branch off an existing session without disturbing the original; the new run starts from the forked session’s history and is assigned a fresh session ID.
Use --tag to attach searchable labels to a run. The flag is repeatable and accepts either a plain name or a JSON object for structured metadata. Pair it with --log-group-id to bucket logs from related runs together for easier filtering and aggregation downstream.

Customizing the system prompt

Use --append-system-prompt to append additional text to the end of the system prompt for a single run, or --append-system-prompt-file to append the contents of a file. Both flags can be combined and are useful for injecting project-specific guidance, style guides, or invariants without modifying global settings.

Mission mode

Mission mode runs droid exec as a multi-agent orchestrator that plans work, delegates to worker agents, and validates results. Enable it with --mission and optionally select dedicated models and reasoning effort levels for the worker and validator roles.

Mission mode flags

FlagDescription
--missionRun in mission mode (multi-agent orchestration).
--worker-model <id>Model ID used by mission worker agents.
--worker-reasoning-effort <level>Reasoning effort for mission workers.
--validator-model <id>Model ID used by mission validator agents.
--validator-reasoning-effort <level>Reasoning effort for mission validators.
The top-level -m, --model and -r, --reasoning-effort flags still apply to the orchestrator itself; the worker and validator overrides only affect the agents the orchestrator spawns.

Batch and parallel patterns

Shell loops (bounded concurrency):
Background job parallelization:
Chunked inputs:
Workflow Automation (CI/CD):

Unique usage examples

License header enforcer:
API contract drift check (read-only):
Security sweep:

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-unsafe unless fully sandboxed.
  • Ask the agent to emit artifacts your pipeline can verify.
  • Use --cwd to constrain scope in monorepos.