Skip to main content

Documentation Index

Fetch the complete documentation index at: https://ade-app.dev/docs/llms.txt

Use this file to discover all available pages before exploring further.

​
Budget caps

Set a Budget cap in tokens or USD when you create a mission. This is the combined ceiling across all workers, not a per-worker limit. When the mission reaches 80% of the cap, ADE raises a budget_limit_reached intervention before work stops. You have three choices:
  • Approve more budget — raise the cap and continue
  • Reduce scope — cancel remaining workers, accept partial results
  • Stop cleanly — the orchestrator wraps up current work and completes with what is ready
The Plan tab’s cost panel shows per-worker token consumption, projected total at the current burn rate, and USD estimates using the configured model’s pricing. If you don’t set a cap, ADE applies the default from Settings → Missions → Default budget cap.

​
Per-provider permission modes

Each provider carries its own permission mode. The mission creation dialog (and the Worker Permissions editor inside it) exposes one row per provider.
ProviderDefault modeWhat that means
Claudefull-autoStandard CLI permissions; agents run without per-step approval
CodexdefaultWorkspace-write sandbox, approval policy on-request
OpenCodefull-autoOpenCode’s standard permission preset

​
Codex sandbox is derived, not chosen separately

The Codex permission mode decides the sandbox:
  • full-auto → danger-full-access (no sandbox)
  • plan → read-only
  • anything else (including default and edit) → workspace-write
There is no separate Codex sandbox dropdown in the Worker Permissions editor anymore — pick the mode and the sandbox follows. Choose config-toml if you want Codex to honor its own ~/.codex/config.toml instead of ADE flags. See AI Providers for the full permission option reference shared across Chat and Missions.

​
Tool palette

Workers reach ADE through the ade CLI. The mission creation form exposes a tool palette (repo, git, github, linear, memory, mission, tests) that maps to the ADE RPC domains each worker may call. Tools outside the palette are rejected at the CLI boundary for that worker.

​
Proof capture

Workers decide when a step deserves proof and call the ade proof CLI directly — screenshot, short recording, or ingested browser trace. There is no mission-wide policy chip; proof is per-step and intentional. Captured proofs link to the mission automatically and land in the Artifacts tab. See Proof Overview for the capture flow.

​
Writable paths

By default, workers can only write inside their assigned lane’s worktree. Extend this with explicit writablePaths entries in the mission permission config — useful when a worker needs to touch shared fixtures or generated files outside its primary lane.

​
Persistence and resume

Mission state is durable. Phases, worker logs, artifacts, and interventions live in ADE’s local SQLite database and the filesystem, and a Mission Pack snapshot is written at every phase boundary. If ADE crashes mid-mission:
  1. Restart the app.
  2. Open Missions — the interrupted run shows in_progress or intervention_required.
  3. ADE reloads from the last Mission Pack snapshot.
  4. Workers that were mid-task resume where they can. Anything that cannot be recovered is marked failed and queued as an intervention.

​
Troubleshooting

Open the Plan tab. If an intervention is open, the worker is waiting for your response. If not, open the Chat tab and ask the orchestrator for a status update. If the worker is genuinely hung, click its card and choose Restart worker to resume from the last checkpoint; Skip task marks the step skipped and lets the mission continue.
Open the Plan tab’s cost panel to find the most expensive workers. You can cancel one worker individually while leaving others running. Approve more budget only when the remaining work is scoped and worth the cost.
A failed_step intervention fires with a test report artifact. Open the artifact, tell the orchestrator what failed in the Chat tab, and let it spawn a follow-up worker scoped to the failing tests. If failures are expected (tests for features not yet built), dismiss the intervention and mark validation skipped.
The approval gate is a hard stop. If you closed the detail view, reopen it from the Missions list — the plan review panel is at the top of the Plan tab’s activity feed.
Click Edit Planning Prompt in the plan review UI, rewrite the prompt to clarify scope or excluded approaches, and click Re-plan. Repeat until the plan matches, then approve.
Common causes: a selected lane is held by another mission, the configured model is not authenticated or is rate-limited, proof-capture prerequisites are missing on the host, or the phase profile has a config error. Each preflight error states the specific gap; fix it and retry.
You are on a packaged (production) build. Mission creation and live runs are paused in production until the orchestration flow is production-ready. Dev and internal builds run Missions end-to-end. See the Missions overview for what the shipping version will do.