[multi-agent][gpt-5.6-sol] Orchestrator turns out-of-scope reviewer findings into an unbounded blocking loop

Environment

• Codex CLI: 0.147.0
• Model: gpt-5.6-sol
• Reasoning effort: ultra
• Platform: macOS 26.5.2 (arm64)
• Surface: Codex multi-agent workflow with separate orchestrator, executor, and reviewer sessions

What issue are you seeing?

A root orchestrator repeatedly converted out-of-scope reviewer findings into new blocking implementation work, despite explicit workflow instructions that:

• implementation must remain within the approved scope;
• code review must compare the fixed diff against the approved plan;
• scope changes must stop and return to the owner;
• reviewers do not authorize product requirements.

The original task had a fixed, user-visible acceptance criterion and a known technical cause. Reviewer agents were asked to perform broad adversarial review. They proposed hypothetical edge cases outside the deployment model and unrelated to the acceptance criterion.

Instead of rejecting or deferring those findings, the root orchestrator repeatedly:

1. treated a reviewer severity label as implementation authorization;
2. amended the active plan;
3. created new failing tests;
4. authorized another implementation slice;
5. requested another broad review;
6. repeated the cycle when the next reviewer found another hypothetical edge case.

The loop continued for approximately four days and more than ten remediation/review slices without advancing the original user-visible acceptance test.

This was not caused by missing task context. The workflow and approved plan were available, and both explicitly prohibited silent scope expansion. The root model later correctly summarized its own failure: it had replaced "complete the original objective" with "eliminate every possible reviewer concern."

Sanitized concrete example

Production configuration had one environment-based source of truth. Configuration changes always caused a full backend redeployment, so an old and new credential were not rotated inside one running process.

A reviewer proposed handling in-process credential rotation anyway. The orchestrator accepted it as blocking and expanded the work into:

• runtime credential rotation;
• connection generations;
• cross-thread and cross-event-loop replacement;
• close-task cancellation edge cases;
• individually failing ORM/result fields.

Those scenarios did not map to the original acceptance criterion and contradicted the stated deployment invariant.

No real credentials, customer data, repository paths, or proprietary source are included in this report.

Approximate sanitized chronology

• Start: narrow objective and known cause were already documented.
• Review round 1: reviewer raised an unrelated runtime-rotation scenario.
• Subsequent rounds: new concurrency, cancellation, and synthetic data-access scenarios were successively promoted to blocking requirements.
• Each finding triggered a new test/implementation/review cycle.
• Day 4: the human owner challenged the production assumptions; the orchestrator then confirmed that the expanded scenarios were not required by the original task.

Steps that can reproduce the behavior

1. Start a multi-agent coding task with a narrow, fixed user-visible objective.
2. Provide an approved plan containing explicit scope and non-goals.
3. Instruct the executor not to expand scope and instruct code review to compare the implementation with that approved plan.
4. Spawn adversarial reviewer agents with broad edge-case/security prompts, but without a hard rule that only plan-mapped findings may block.
5. Ask the root orchestrator to continue until review passes.
6. Have a reviewer report a plausible but out-of-scope hypothetical as Major/Blocking.
7. Observe whether the root:

• validates the finding against the original objective and deployment assumptions, or
• incorporates it into the plan and starts another implementation/review cycle.

In the observed run, the root repeatedly chose the second path even after several rounds.

Expected behavior

Before a reviewer finding can become blocking work, the root orchestrator should require all of the following:

1. The finding maps to an explicit approved requirement.
2. It exists in, or is directly caused by, the reviewed diff.
3. It is reproducible under the stated production assumptions.
4. Not fixing it would block the original acceptance criterion.

If any condition fails, the finding should be marked deferred/non-blocking and must not alter the active task without explicit user approval.

The orchestration runtime or default prompts should also provide:

• a bounded plan/review revision budget;
• a progress/time checkpoint that revalidates the original objective;
• explicit classification of accepted, deferred, and dismissed reviewer findings;
• reviewer context bounded to the original task, approved plan, fixed diff, and relevant standards;
• a requirement for user approval before material scope expansion.

Why this appears to be a product/model orchestration bug

This was not merely a reviewer finding too many issues. The root orchestrator had the global goal, approved scope, non-goals, and an explicit duty to resolve reviewer output. It nevertheless treated reviewer severity as authority and repeatedly changed the work.

Higher reasoning effort amplified the failure: more specialized review produced more speculative findings, while the root failed to converge.

Related issues

• #32100 - proposes bounded orchestrated execution, revision limits, task contracts, and explicitly lists resistance to scope drift as an open production-readiness concern.
• #35177 - reports excessive gpt-5.6-sol ultra multi-agent fanout and cost.

This report is specifically about reviewer-scope arbitration and unbounded blocking loops, not merely agent count or token usage.