Missions Configuration & Reference

Configuration inheritance, headless execution with droid exec --mission, mission settings, and enterprise access policy.

Configuration inheritance

Missions inherit your existing Droid configuration:

MCP integrations: Workers can use your connected tools (Linear, Sentry, Notion, etc.)
Custom skills: Your existing skills are available and new ones can be developed during planning.
Hooks: Lifecycle hooks fire during mission execution.
Custom droids: Subagents configured in your project are available to workers.
AGENTS.md: Workers follow your project conventions and coding standards.

Headless mission execution

Missions can also run non-interactively via droid exec --mission. This is useful for CI, scheduled jobs, and any environment where you want the orchestrator to plan and execute without a live TUI.

Bash

droid exec --mission -f mission.md

You can override the models and reasoning effort used by the orchestrator's worker and validator agents:

Bash

droid exec --mission \
  --worker-model claude-sonnet-4-6 \
  --worker-reasoning-effort medium \
  --validator-model claude-opus-4-7 \
  --validator-reasoning-effort high \
  -f mission.md

Flag	Description
`--mission`	Run `droid exec` in Mission Mode (multi-agent orchestration).
`--worker-model <id>`	Model used for mission worker agents.
`--worker-reasoning-effort <level>`	Reasoning effort for mission worker agents.
`--validator-model <id>`	Model used for mission validator agents.
`--validator-reasoning-effort <level>`	Reasoning effort for mission validator agents.

See droid exec for the full headless reference.

Configuration

Missions are tuned through the missionModelSettings object and a few top-level keys. Set these in your global or project settings file.

Setting	Description
`missionModelSettings.workerModel`	Default model used by mission worker subagents.
`missionModelSettings.workerReasoningEffort`	Reasoning effort for mission workers (`off`, `none`, `low`, `medium`, `high`).
`missionModelSettings.validationWorkerModel`	Model used by validation workers (scrutiny and user-testing).
`missionModelSettings.validationWorkerReasoningEffort`	Reasoning effort for validation workers.
`missionModelSettings.skipScrutiny`	Skip scrutiny validation milestones during missions.
`missionModelSettings.skipUserTesting`	Skip user-testing validation milestones during missions.
`missionOrchestratorModel`	Model used by the mission orchestrator.
`missionOrchestratorReasoningEffort`	Reasoning effort for the mission orchestrator.
`keepSystemAwakeDuringMissions`	Prevent the OS from sleeping while a mission is running. Defaults to `true`.

Tip

Pairing a strong orchestrator model with a faster worker model is a common cost-quality tradeoff: planning and validation benefit most from extra reasoning, while routine worker tasks can use a lighter model.

Enterprise: restricting mission access

Organizations can restrict who is allowed to launch missions through the missionPolicy org-level setting:

JSON

{
  "missionPolicy": {
    "restrictedAccess": true,
    "allowedUserIds": ["user_123", "user_456"]
  }
}

When restrictedAccess is true, only members listed in allowedUserIds can start new missions. See the settings reference for the full enterprise policy surface.

Related resources

Droid Exec (Headless)

Run missions non-interactively with droid exec --mission.

Enterprise Controls & Managed Settings

Govern mission access and model policy at the organization level.