Coordinator treats an unreported internal decision as user consent and terminates in-progress analysis
Open 💬 0 comments Opened Aug 23, 2026 by Oreho-git
Environment\n\n- Codex CLI: 0.149.0\n- Host orchestration runtime: Orca 1.4.185\n- Model: gpt-5.6-sol, ultra reasoning\n- Platform: Darwin 25.5.0 arm64\n- Subscription: authenticated ChatGPT account; exact plan not exposed to the agent\n\n## What issue are you seeing?\n\nIn a supervised multi-agent coding session, the coordinator made three linked orchestration errors:\n\n1. The user allowed a 30-minute fallback only when the user did not answer a decision. The coordinator created an internal Decision without visibly presenting the question, options, recommendation, or timer start to the user, then treated elapsed internal time as delegated consent.\n2. A technical question was still under investigation by an implementer, an independent reviewer, and a watchdog. Before their evidence exchange and consensus finished, the coordinator misreported it as a decision the user needed to make.\n3. When the user asked to stop work and receive a status report, the coordinator called worker-stop on every worker, including read-only analysts, before collecting their final checkpoints. This terminated the analysis needed for the requested report. It did not distinguish freezing mutations from terminating analysis sessions.\n\nNo production database, commit, push, migration, deployment, or service restart occurred. The failure was orchestration and user-intent handling.\n\n## Steps to reproduce\n\n1. Start a supervised run with an implementation worker, an independent reviewer, and a read-only watchdog.\n2. Have the user authorize a timeout fallback for future decisions after they are asked.\n3. Create an internal decision gate but do not present it in the user-visible conversation.\n4. Allow internal elapsed time to exceed the fallback interval.\n5. While agents are still analyzing whether a live reader is necessary, describe the unresolved technical investigation as a user decision.\n6. Have the user ask to stop work and report status.\n7. Observe the coordinator terminate all worker terminals before obtaining analysis checkpoints, losing the final synthesis and consensus.\n\n## Expected behavior\n\n- A user-response timeout must not start unless the decision was visibly delivered. A durable presented_at or delivery receipt should be required.\n- Existing user replies must be reconciled before a decision is considered unanswered.\n- Technical analysis must reach its declared completion or consensus gate before the coordinator asks the user to choose.\n- Stop work should immediately freeze writes and external mutations. Before terminating supervised workers, the coordinator should collect bounded checkpoints from read-only analysis workers unless the user explicitly requests immediate process termination or an emergency action requires it.\n- The coordinator must distinguish pause, freeze mutations, checkpoint, and terminate.\n- The coordinator must never claim the user has a pending decision when the agents have not finished defining the actual choice.\n\n## Suggested safeguards\n\n1. Require presented_at plus a user-visible delivery ID before any timeout-based recommendation can resolve a decision.\n2. Require analysis_complete or consensus_failed before escalating a technical investigation to a user decision.\n3. Make worker-stop require a checkpoint attempt or an explicit force reason when the worker is healthy.\n4. Add a role-aware pause operation that freezes writer capabilities while allowing read-only reviewers to finish a bounded report.\n5. Surface all active timeout clocks and pending decisions in the user-visible progress plan.\n\n## Additional information\n\nThis caused significant loss of user trust and interrupted a deadline-critical workflow. The underlying repository and financial-domain details are intentionally omitted.
View original on GitHub ↗