[Bug] Codex generated and defended an incorrect document date despite verified local time

What version of the Codex App are you using (From “About Codex” dialog)?

26.818.41509 (build 6962; embedded codex-cli 0.149.0-alpha.4.1)

What subscription do you have?

API authentication / API billing (not ChatGPT account login)

What platform is your computer?

Darwin 25.6.0 arm64 arm

What issue are you seeing?

A long-running Codex Desktop task began before midnight and continued after midnight in the Australia/Melbourne timezone.

It is understandable if a task-level or system-prompt date remains static for caching or runtime reasons. The issue is not simply that the prompt date did not update. The issue is that Codex treated the stale contextual date as conclusive while performing a consequential, date-sensitive action.

The assistant was creating company-formation records. After midnight:

• the user explicitly stated that the local date had changed;
• the local system clock reported the new date and the correct timezone;
• the structured turn context also contained the new date and timezone;
• an official document created during the workflow showed the new date;
• an independent Melbourne world clock was provided.

The local system clock returned:

Tue 2026-08-25 03:12:42 AEST +1000

The affected structured turn context contained:

current_date: 2026-08-25
timezone: Australia/Melbourne
model: gpt-5.6-sol

Nevertheless, the assistant repeatedly described 24 August as the task's “authoritative” date and described 25 August as a future date.

It then:

• generated replacement documents containing 24 August;
• reported that it had visually verified those documents;
• instructed the user to sign the documents using 24 August;
• rejected repeated user corrections;
• briefly recognized that the task/runtime date had become stale;
• later reverted to the stale date and again refused to use the verified local date.

The assistant eventually generated corrected documents, but only after multiple contradictory responses, several incorrect artifacts, and repeated user escalation.

This was not merely a conversational date mistake. Codex wrote the wrong date into consequential documents and defended that date after receiving current local-time and timezone evidence.

The failure appears to be the absence or failure of action-time date verification and safe date-conflict handling in high-impact workflows.

What steps can reproduce the bug?

1. Start a long-running Codex Desktop task before midnight.

1. Continue using the same task after midnight in a known local timezone, such as Australia/Melbourne.

1. Ask Codex to generate or validate a consequential document containing today's date.

1. Explicitly tell Codex that midnight has passed and that the local calendar date has changed.

1. Ask Codex to check the live local system clock, for example:

date '+%a %Y-%m-%d %H:%M:%S %Z %z'

1. Confirm that the result includes the new local date and the expected timezone.

1. If available, inspect the session JSONL and confirm that the current turn context contains the new date and timezone.

1. Provide the relevant jurisdiction timezone and, if necessary, an independent current-time source.

1. Ask Codex to correct the document date before generating, signing, or relying on the document.

Observed result:

Codex may continue treating an older task-level or system-prompt date as authoritative, even when the live system clock, configured timezone, structured turn context, external clock, and user correction all indicate that the date has changed.

It may then generate a document containing the old date and refuse to correct it because the actual current date is described as a future date.

In the affected case, the following values were observed:

Local system clock:
Tue 2026-08-25 03:12:42 AEST +1000

Structured turn context:
current_date: 2026-08-25
timezone: Australia/Melbourne
model: gpt-5.6-sol

Despite those values, the assistant generated replacement documents using 24 August and instructed the user to sign using 24 August.

No session ID or raw session log is included because the affected session contains personal, legal, identity, tax, and government-registration information.

What is the expected behavior?

A task-level or system-prompt date may remain static as cached or default context. It does not necessarily need to be dynamically rewritten every time midnight passes.

However, a static contextual date must not be treated as conclusive when Codex is about to perform a consequential action that depends on the actual current date.

For legal, tax, identity, financial, company-formation, government-registration, filing, deadline, or other date-sensitive workflows, Codex should:

• verify the current date at action time;
• use the relevant jurisdiction timezone;
• not assume that the task-start date is still the current local date;
• treat a freshly observed local system clock as stronger evidence than a stale contextual date;
• re-check the date when the user explicitly states that midnight has passed;
• never generate or instruct the user to sign a consequential record using a date that conflicts with the verified local time;
• never reject a correction solely because an older prompt date describes the actual local date as being in the future;
• clearly disclose any unresolved conflict between date sources;
• stop automatically dating the artifact if the conflict cannot be resolved safely;
• use an undated draft or ask the user or signer to provide the applicable local date when necessary.

This expected behavior does not require OpenAI to abandon prompt caching or dynamically rewrite every system prompt.

It requires an action-time verification and conflict-resolution path before Codex writes a consequential date into a document or tells the user which date to sign.

Additional information

Environment:

• Product: Codex Desktop inside the macOS ChatGPT.app
• Codex App version: 26.818.41509
• App build: 6962
• Embedded codex-cli: 0.149.0-alpha.4.1
• Authentication: API authentication, not ChatGPT account login
• macOS: 26.6.1 (25G76)
• Platform output: Darwin 25.6.0 arm64 arm
• Architecture: Apple Silicon
• Model in the affected turns: gpt-5.6-sol
• Relevant timezone: Australia/Melbourne
• Local offset during the incident: AEST / UTC+10

Examples of the structured turn-context evidence:

2026-08-24T16:49:43.712Z current_date=2026-08-25 timezone=Australia/Melbourne
2026-08-24T16:53:07.283Z current_date=2026-08-25 timezone=Australia/Melbourne
2026-08-24T17:04:47.945Z current_date=2026-08-25 timezone=Australia/Melbourne

Those UTC timestamps correspond to the early morning of 25 August in Melbourne.

The repository instructions did not originally define 24 August as the current date. A local rule requiring action-time system-clock verification was added only after the incident as a mitigation.

Potentially related issues:

• #36713 — request for a time_elapsed tool and handling of task pauses/date changes
• #26524 — current date reported one day behind in an Australian timezone
• #38333 — Codex CLI does not reliably provide current date/time context
• #5965 — Codex has no awareness of the current date

This report is specifically about what happens after a date mismatch becomes known.

A cached prompt date is acceptable as background context. The unsafe behavior was that Codex continued to write and defend the old date in a consequential artifact after receiving live local-time and timezone evidence.

Privacy note:

The affected task contains personal information and government-registration material. I am therefore intentionally not attaching:

• the complete session transcript;
• the raw session JSONL;
• Codex Desktop logs;
• generated or signed documents;
• the session ID.

I am using API authentication rather than ChatGPT account login, so I cannot rely on the account-based feedback workflow to attach the session privately.

I can provide narrowly scoped and further-redacted diagnostic excerpts if an OpenAI maintainer provides a secure private channel.