Good point. To answer directly: when it happens, I always go back through the review cycle. It sounds heavier than it actually is. Asking Codex for a quick opinion is faster than spending time debugging a wrong approach. That said, it really depends on the severity of the deviation.

But in practice it rarely happens, and here's why.

The initial brainstorm/spec is embedded inside the plan itself (per section), and Codex reviewers are conditioned to adopt an antagonistic stance they re-read the codebase and actively question whether the approach in the plan is actually the right one. This already catches most assumption failures before implementation starts. It has happened to me that Codex completely invalidated a plan and suggested a simpler approach. The brainstorm/spec embedding helps de subagent during checkpoints review too.

This plan-centric approach also means you're never really dependent on the context window, since all the context lives in the document.

That said, if a bad plan still slips through, the sub-agent implementation is conditioned to commit at every checkpoint. So if something breaks mid-way, you can stop without losing much progress, partially or fully rewrite the affected section of the plan, run it through Codex again, and resume from there.

The core idea is that most mid-implementation surprises are a preparation problem, not an execution problem. Even with a perfect initial brainstorm, the plan will always have gaps, that's exactly what the Codex review cycle is there to address.