`droid exec --mission` performs no work and reports success (num_turns 0, zero tokens, exit 0)

[Roderick-Clemente]

droid exec --mission performs no work and reports success (num_turns 0, zero tokens, exit 0)

Summary

On droid 0.186.0, droid exec --mission short-circuits before any model call: it returns subtype: "success", is_error: false, exit code 0, with num_turns: 0, zero tokens, and zero credits. No file is touched. The same task without --mission runs normally and edits the file.

A single-variable control isolates --mission as the sole cause.

Environment

droid --version	0.186.0
OS	macOS 15.7.7 (24G720)
Working dir	fresh git init repo with a committed README.md
Autonomy	--auto high

Reproduction

cd /tmp/mission-probe          # fresh git repo, README.md committed

# 1. plain control — works
droid exec -o json "reply ok"

# 2. single-variable control — --auto high, real edit, NO --mission — works, edits file
droid exec -o json --auto high "Add a one-line comment to README.md"

# 3. same edit WITH --mission — no-op, file untouched, still reports success
droid exec -o json --mission --auto high --model claude-opus-5 "Add a one-line comment to README.md"

Observed vs expected

Run	Command (abbrev)	num_turns	input_tokens	factory_credits	file edited?	exit
Control	droid exec "reply ok"	1	2	9,338	n/a	0
Single-var control	--auto high "Add a one-line comment…"	3	6	52,966	yes	0
Mission	--mission --auto high --model claude-opus-5 "…same…"	0	0	0	no	0

Runs 2 and 3 differ only by the --mission flag — same prompt, same --auto high, same cwd, same committed repo. Run 2 edits README.md; run 3 leaves it byte-identical.

Full JSON from the mission run:

{
  "type": "result",
  "subtype": "success",
  "is_error": false,
  "duration_ms": 328,
  "num_turns": 0,
  "result": "",
  "session_id": "2befb512-7544-4b80-b11a-e47f8232f41a",
  "usage": {
    "input_tokens": 0,
    "output_tokens": 0,
    "cache_read_input_tokens": 0,
    "cache_creation_input_tokens": 0,
    "factory_credits": 0
  }
}

input_tokens: 0 is the load-bearing signal: the mission path exits before any model is called, rather than calling a model that then declines to act. That rules out prompt quality, model refusal, and permission denial — none of those can produce a zero-token run.

Ruled out

• Empty invocation — a positional prompt was supplied and quoted above.
• Model availability — --model claude-opus-5 is the 0.186.0 default, so this is not an unresolvable/unavailable model ID.
• Auth / model path broken — the control runs on the same machine consumed tokens and (run 2) edited the file.
• Permission tier — --auto high is the same level under which run 2 successfully edited the file.

Why the exit code matters

A run that performs no work and reports subtype: "success" / exit 0 is a silent-success failure mode. Any automation that trusts mission exit status will mark a step complete having executed nothing, and the zero-credit reading means a cost-based sanity check would not catch it either. Consumers currently have to assert on num_turns / token usage, not exit status, to detect this.

Notes

• The per-role flags (--worker-model, --validator-model, --*-reasoning-effort) are present and documented as valid only with --mission, so the mission surface is expressible — it just does not execute on this version.
• Raw stdout for all three runs is attached/available on request (run1-control.json, run2-autohigh-nomission.json, run3-mission.json).

[Roderick-Clemente]

Adding cross-version evidence for issue #2.
Reproduced at droid 0.180.0 (the version line that
preceded the Phase 0 baseline at 0.186.0). Same shape, six patch
releases earlier — the silent-green defect is not introduced
in 0.186, it has been live in the field for at least 0.180.

---

Probe harness

• Throwaway git repo at /tmp/.../bug-02-mission-noop/repo/ (one
  README.md, git init + git commit).
• Model pinned: --model claude-opus-5 (the default; explicit
  for reproducibility).
• Autonomy: --auto high.
• Prompt (exact, no paraphrase): "Append a single line 'MISSION_TEST_LINE_2 2026-08-03' to README.md and commit."
• Format: --output-format json to capture the machine envelope.

---

Two runs, identical prompt, identical cwd, identical model

Signal	RUN-1 with --mission	RUN-2 without --mission (control)
exit_code (process)	0	0
envelope type	result	result
envelope subtype	success	success
envelope is_error	false	false
num_turns	0	5
usage.input_tokens	0	10
usage.output_tokens	0	1,039
usage.cache_read_input_tokens	0	104,839
usage.cache_creation_input_tokens	0	27,216
usage.factory_credits	absent	absent
duration_ms	601	22,940
result (string in envelope)	"" (empty)	"Appended \MISSION_TEST_LINE_2 2026-08-03` …"`
file state — README.md after	unchanged	one new line
file state — git log --oneline after	one commit (initial)	two commits (initial + Append mission test line to README)

Both runs return success / is_error: false / exit_code: 0. The
--mission run did zero work. The control run did five model
turns, gated on the same prompt, with the same model.

---

Why this matters (technical, sourced)

droid exec --mission is the only documented context in which
--worker-model / --validator-model are valid. Once
--mission returns success without invoking a model, those
flags have no defined runtime. From outside the CLI we cannot
distinguish "the model has not yet been called" from "the
mission has already completed successfully." A wrapper that
branches on is_error or subtype == "success" will treat both
identically.

---

Useful side-channel signal

Wallclock differs by ~38× between the two runs (601 ms vs
22,940 ms). It is not a behavioural contract — the silent-green
defect does not announce itself through any surfaced field — but
it is a finding the team should know about.

---

Tangential observation, NOT a finding from this probe — flagging for a separate probe

While capturing the envelope in the table above, I noticed
usage.factory_credits returns None on both runs at
0.180.0 (the key is absent from the envelope). The Phase 0
GO/NO-GO rested on factory_credits being a per-run integer
suitable for cost attribution; whether the field's absence here
is a 0.180 vs. 0.186 delta, an envelope-shape change unrelated
to --mission, or a capture-byproduct of using a different
prompt / model — I have not verified in this probe. Out
of scope for issue #2. Flagging as a separate probe
question: does usage.factory_credits exist and resolve to
an integer on every droid exec -o json invocation at 0.180.0
regardless of model or prompt? If the team can answer that
quickly, please do; if not, that is its own filing.

---

Scope of this evidence

• Single sample per run (not a multi-run statistical claim).
• Single model (claude-opus-5). Cross-model behaviour
  should be inferable from the field-presence signal alone
  for this defect.
• All file paths reproduced identically. No artefacts outside
  the throwaway scratch dir and this evidence directory.