Override validation uses the image the tick runs with - #447
Conversation
…UTERLOOP_IMAGE is unset) Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Round 1 — reviewed head 85213199 — reviewer summarizer:hermes/gpt-5.6-terra over coverage+credentials+deployment+general+lifecycle+prose.
terra
Advisory findings from outerloop — the code owner decides. Reply to disagree; the outerloop:no-review label opts this PR out.
Verdict: 1 blocking, 0 advisory.
1 finding attached to the lines below.
Merged one blocking finding: coverage, credentials, deployment, general, lifecycle, and prose agree that explicit empty image settings make start-time and tick-time override validation disagree. Rejected findings: none; all submitted findings describe the same defect at src/outerloop/cli.py:620.
There was a problem hiding this comment.
Round 1 — reviewed head 85213199 — reviewer hermes/gpt-5.6-terra.
terra
Advisory findings from outerloop — the code owner decides. Reply to disagree; the outerloop:no-review label opts this PR out.
Verdict: 1 blocking, 0 advisory.
1 finding attached to the lines below.
The start command accepts a Codex override with the explicit no-image setting, then launches a tick that rejects it.
… empty means none Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Round 2 — reviewed head 1346a6cb — reviewer hermes/gpt-5.6-terra.
terra
Advisory findings from outerloop — the code owner decides. Reply to disagree; the outerloop:no-review label opts this PR out.
Verdict: 1 blocking, 0 advisory.
1 finding attached to the lines below.
Start can validate a different image from the tick when the environment and .env both set OUTERLOOP_IMAGE.
…hen environment, then default Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Round 3 — reviewed head 47fd7817 — reviewer hermes/gpt-5.6-terra.
terra
Advisory findings from outerloop — the code owner decides. Reply to disagree; the outerloop:no-review label opts this PR out.
Verdict: 1 blocking, 0 advisory.
1 finding attached to the lines below.
Local and login starts can validate a different image from the tick they launch.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Found on a live deployment before it could hurt it. The tick runs sessions with
OUTERLOOP_IMAGE, falling back to the default image, but its startup validation ofOUTERLOOP_AUTHOR_OVERRIDESusedOUTERLOOP_IMAGEfalling back to an empty string. On a deployment that leavesOUTERLOOP_IMAGEunset (its codex authors run fine on the default image), adding a codex override made validation fail with "requires --image", and that failure exits the tick throughparser.error: a whole-fleet outage.outerloop starthad the same mismatch.What changes
tick.startup_image(): the one place that decides the session image (OUTERLOOP_IMAGE, else the default). The service spec and startup validation both use it.outerloop startvalidates with the same default when the setting is unset.Compatibility (RELEASING.md)
No persisted state. Deployments that set
OUTERLOOP_IMAGEbehave exactly as before; deployments that do not can now use codex overrides.Tests
The production case (codex override,
OUTERLOOP_IMAGEunset) validates with the tick's image and fails with the old empty image; a guard that the tick's entry point validates withstartup_image()(mutation-checked: reverting the call fails it). Gate: 2755 passed, 10 skipped; ruff, format, mypy clean.🤖 Generated with Claude Code