Long-running Codex tasks lose state and overstate background execution or completed outcomes

What issue are you seeing?

During a long-running, multi-workstream Codex session, status language repeatedly implied that tasks were actively running or completed when verified external outcomes did not support those claims. Local drafts, prepared packages, delegated instructions, and queued work were sometimes described like uploads, publications, sends, or completed delivery.

The assistant also said work was running, in motion, or continuing in parallel when no durable executor was continuously active. Repeated checking/routing/waiting loops often replaced a concrete result, blocker, or user decision. Voice interruptions and reconnects caused context loss, repeated questions, conflicting claims, and stale browser or task-owner assumptions. Counts sometimes mixed local artifacts, activity events, unique recipients, submissions, and verified outcomes.

The user had to repeat instructions and supervise constantly, while receiving too few externally verified results. This made it difficult to trust whether a task was active, merely prepared locally, blocked, submitted, or actually complete.

What steps can reproduce the bug?

1. Start a long-running task with several independent workstreams, external destinations, and approval gates.
2. Ask Codex to continue the work in parallel and report verified outcomes.
3. Leave the computer available for overnight or hourly automation, expecting the next safe, authorized unit of work to execute.
4. Interrupt or reconnect through voice, then resume the task.
5. Compare status statements such as 'running,' 'in motion,' or 'continuing in parallel' with the actual executor and external destinations.
6. Observe that scheduled or overnight activity may only wake, restate status, and go quiet instead of advancing safe work; local drafts or delegated instructions may be described too similarly to external completion.
7. Observe repeated checking and waiting narration, stale session assumptions after reconnect, and counts that are not reconciled into unique verified outcomes.

No session logs or private account data are attached.

What is the expected behavior?

Codex should use explicit, visible states for every deliverable: not started, working in current turn, persistent executor active, local artifact, QA passed, ready for external action, submitted, confirmed live, blocked, or needs user action.

'Running in the background' should be used only when a real persistent executor exists and its lifecycle is visible. Overnight or hourly automations should perform the next safe, authorized unit of work and record evidence, while stopping for authentication, legal certification, money movement, or final public submission.

Sends, uploads, publications, deployments, and account changes should never be reported as complete without visible destination confirmation. Voice reconnects and app restarts should reconcile or invalidate stale state automatically. A concise dashboard should show the task owner, current action, last evidence, blocker, and next step, with unique outcome counts.

Additional information

Product/value context: the user reports paying about $200 per month for their subscription and feels the delivered experience did not justify that cost; based on the value received, it felt closer to a $20 product. This is the user's reported subscription cost and value assessment, not a statement of official Codex pricing. Despite impressive capabilities and substantial time invested, the work produced no income for the user. They genuinely need this assistance, but repeated loops, loss of focus, overstated execution, and limited verified external results made the experience exhausting.

Related integration gap: there is no safe, structured path for Codex to help report public-infrastructure hazards to the correct utility or telecommunications provider. A useful integration would verify the provider and location, support emergency escalation, suppress duplicates, protect privacy, allow anonymous reporting where lawful, and return a delivery receipt. Current support bots and account-only flows often cannot accept responsible AI-assisted reports.

Requested improvements also include a built-in, privacy-reviewed 'report this session' action that returns a receipt ID. This report intentionally excludes private business names, credentials, financial account details, guest information, access codes, session logs, and attachments.

No files, tests, or entry points are identified in the issue. Start by reproducing a multi-workstream task across interruption and reconnect, then trace how execution state and status claims are stored and reconciled. Done should include distinct visible states, verified external outcomes, and consistent recovery after reconnects.