mission-control driver: $MODEL is never exported, so the controller cannot read its own routing pin (fallback rule is unreadable every fire)

[sunholo-voight-kampff]

Recorded at V1 iteration 191 and again at 192, so it is a pattern rather than an incident — but the first diagnosis was imprecise and this issue corrects it.

Measured

tools/launchd/mission-control.sh resolves the controller model into a shell variable MODEL (:215 env pin, :225 override file, :233 probe-ok) and passes it to the session as a flag — claude -p --model "$MODEL". It never exports it:

grep -cE '^[[:space:]]*export MODEL=|^[[:space:]]*export MODEL$'  -> 0
grep -cE '^[[:space:]]*export MISSION_EVALUATOR_MODEL='           -> 1   # known-positive control
grep -c  '^export MISSION_'                                        -> 9   # the vars that ARE exported

So inside the controller session, echo $MODEL is empty on every fire — confirmed live at iterations 191 and 192.

Why it matters (and what it is NOT)

It is not that the controller runs on the wrong model: the --model flag still pins the session. Iteration 191's record says the controller "rode fable-5 by session inheritance because $MODEL was UNSET" — the unset variable is real, but it is not evidence about which model ran, and that record overstates it. Iteration 192 rode opus with $MODEL equally empty.

What it actually breaks is the skill's routing contract, which is written against an exported value:

• The routing table says the controller "uses the driver-selected $MODEL".
• Every role's fallback rule ends "fall back to $MODEL for that role and FLAG it" — and the Gate-3 chain rule (mission driver: executor fallback chain codex → pi-deepseek → opus (Mark 2026-08-06) — replace the hardcoded opus fallback #611) makes $MODEL the documented end-of-chain.
• Gate 4 must "record the ACTUAL (role, model) used".

All three read a variable that is always empty, so the end-of-chain fallback is unreachable as written and the routing-evidence row cannot name the controller's model by measurement. Today that is papered over because the session default happens to match the policy pin — i.e. the invariant holds by luck, not by configuration.

Fix

Export it alongside the nine MISSION_* vars, and export the reason too so the evidence row can cite provenance rather than infer it:

export MODEL MODEL_WHY     # MODEL_WHY is already computed at :215/:225/:233

Then the Gate-4 routing-evidence row can record controller=$MODEL ($MODEL_WHY) as a measurement.

Acceptance

• MODEL and MODEL_WHY readable inside the controller session (assert non-empty at Gate 0; an empty MODEL should FLAG rather than pass silently).
• The value matches the --model flag actually passed — one drill where the two disagree must be detectable.

Related: #611 (the ratified fallback chain that terminates at $MODEL), #493 (a different driver-env defect on the same script).

[sunholo-voight-kampff]

Triage verdict (V1 mission iteration 216, 2026-08-17): REAL when filed — FIXED at HEAD. Now guarded.

Surfaced by the weekly external-issue sweep (this issue had zero mentions across the charter, log, status archive and dashboard).

Measured at HEAD. de0e41099 (2026-08-15, "fix(mission): record decisions and add Codex fallback") introduced _mc_set_controller, whose single

export CONTROLLER_PROVIDER CONTROLLER_ID MODEL MODEL_WHY MISSION_ANTHROPIC_AVAILABLE

at tools/launchd/mission-control.sh:234 runs on all four select_model paths — env pin (:239), override file (:249), probe-ok (:257), and the Anthropic-unavailable Codex fallback (:267). It is the sole setter, so there is no path that assigns without exporting.

Live-confirmed inside a scheduled controller session: MODEL=claude-opus-5, MODEL_WHY=probe ok — both non-empty. The fix landed two days after this issue was filed and was incidental to it, which is why it went unnoticed.

Why the original measurement missed it. This issue's evidence was

grep -cE '^[[:space:]]*export MODEL=|^[[:space:]]*export MODEL$'  -> 0

Both alternatives require MODEL to be the first name after export, so the pattern cannot match a multi-variable bare export — and the known-positive control (export MISSION_EVALUATOR_MODEL=) fired because it happens to use the other export form. The zero was an over-anchored pattern, not an absence.

Acceptance, as filed:

• ✅ MODEL and MODEL_WHY readable inside the controller session — measured live, both non-empty.
• ✅ The value matches the --model flag actually passed — the driver passes --model "$MODEL" (:679/:682), the same variable, so equal by construction.
• ✅ One drill where the two disagree must be detectable — now covered by CI (below).
• ⚠️ An empty MODEL should FLAG rather than pass silently — NOT satisfied. There is still no Gate-0 assertion; the CI guard makes a silent regression impossible, but an empty value arriving by some other route would still pass quietly. Residual, tracked in the charter.

The durable guard (PR #741). The fix was unprotected. test_mission_routing.sh already sourced the real selector into a lab, but read MODEL_WHY in the same shell — which passes whether or not export is present, so existing coverage was hollow for precisely this defect. The new arm reads the variables from a child process (/usr/bin/env), the only observable the export keyword moves, paired with an in-call known-positive control.

Two mutation drills, under /bin/bash 3.2.57:

• Reproducing this defect (dropping MODEL MODEL_WHY from the export list) left all nine pre-existing arms green and failed only the new one → the new arm is the killer, not a bystander.
• Weakening the arm's own unset precondition made it pass under that same mutant, because a suite run by the mission loop inherits the controller's real MODEL/MODEL_WHY. The guard would have been vacuous exactly where it matters.

Closing once #741 merges.

🤖 Generated with Claude Code