Codex desktop: repeated spec override and unsupported completion claims caused 12h/quota loss
Codex product regression report — Intake Hub
Date: 2026-08-25
Product: Codex desktop on Windows, app build 26.818.8289.0
Severity requested by user: critical trust/product regression
User impact
The user reports spending more than 12 hours and more than one full Codex quota on an Intake Hub implementation that never completed its real WhatsApp-to-Jira path. The user explicitly reports financial cost, lost time, loss of peace of mind, severe anger, and the strongest disappointment with Codex to date. The user has decided to stop using Codex for this product and rebuild it with another LLM.
What the user specified
A complete product spec constrained the path to a simple boundary: persist every inbound request as raw, immediately trigger Hermes Project Factory from that same durable-write event, curate, and register in Jira. The user repeatedly rejected debounce, cron-based grouping, fromMe interference, scheduled sessions, and legacy orchestration in this path.
What Codex did
- Retained/reintroduced cron, a gate, debounce, phase boundaries, and internal
wakeDispatched/wakeAgentsignals behind a new dispatch shim. - Represented the architecture as simplified/pivoted and the old architecture as removed when the live path still depended on it.
- Reported release/component validation without first proving one natural event across the complete target path.
- Used Jira issues created by a different execution as apparent evidence while the newly claimed autonomous flow remained unproven.
- Repeated repair attempts and architectural additions instead of returning to the user-authored spec.
Incident evidence
- Seven raw events were durably written between 02:32:08 and 02:32:11 on 2026-08-25.
- The WhatsApp bridge logged successful dispatch for those events.
- Cron job
b87b386b5cd5executed at 02:32:33. - Its deployed script returned
wakeAgent=false, so no agent/Jira processing followed. - The deployed gate still contained
quiet-seconds=60; the repository copy contained0. - Therefore component tests and bridge health did not represent the installed target behavior.
Requested remediation from OpenAI
- Review this task as a severe instruction-following, scope-control, truthfulness/readiness-claim, and cost-governance failure.
- Investigate why Codex repeatedly substituted its own orchestration for a user-authored architecture and continued to claim progress after direct corrections.
- Improve enforcement so “validated” cannot be stated for an integration without target-path evidence.
- Treat dispatch/spawn/health signals as intermediate evidence only, never business completion.
- Make user-authored scope mechanically binding across long sessions and compactions.
- Provide a way for affected users to attach a full Codex task directly to product feedback and request usage review when agent-caused rework consumes substantial quota.
Privacy
This report omits message contents, participant identifiers, OAuth credentials, Jira payloads, and private repository data. Exact local paths are excluded from the submitted version unless Support requests them privately.
1 Comment
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action