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/wakeAgent signals 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 b87b386b5cd5 executed 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 contained 0.
• 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.

No source file or test is named. Start by tracing the WhatsApp bridge dispatch, cron job b87b386b5cd5, deployed gate, and wakeAgent/wakeDispatched signals against the repository configuration. Done requires evidence of one natural event traversing the requested raw-write-to-Hermes-to-Jira path, with validation claims based on that target path rather than component health or unrelated Jira issues.