Codex App: repeated current-date developer context causes tool-loop repetition and role drift

[Yuimi-chaya]

Authentication: API login.

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

26.803.10989.0

What subscription do you have?

API login

What platform is your computer?

Microsoft Windows NT 10.0.26120.0 x64

What issue are you seeing?

In two separate Codex App tasks using gpt-5.6-sol with high reasoning, a static high-priority current-date instruction became an apparent repetition attractor during long tool-running turns.

The instruction was:

The current date is Thursday, August 13, 2026. Any dates before this are in the past, and any dates after this are in the future.

Codex should use this as silent background context. Instead, after multiple tool completions/resumptions, the assistant began explicitly acknowledging it in almost every commentary update with phrases equivalent to "the date baseline is confirmed" or "I will not repeat the date again." It then repeated the acknowledgement on the next continuation anyway.

The behavior became mechanical and self-reinforcing:

1. A tool call or reviewer wait completed.
2. The assistant resumed generation.
3. It explicitly acknowledged the same date instruction again, although the user had not asked about dates.
4. That acknowledgement entered the task history.
5. Later continuations increasingly copied the same pattern.

This was followed by more serious task-state corruption. In one task, the assistant lost the top-level implementation objective and treated a temporary internal code-review subtask as its main role. Its final response became a pure review report even though the user had asked it to continue implementing, build, and commit the fix.

This is not merely repetitive wording: the assistant's active task frame and role drifted after the repeated high-priority-instruction acknowledgements.

Affected task IDs:

• 019ffa0e-032b-71e0-8eba-28ab29d3763f
• 019f516e-8c89-7872-8c81-e6d7ad99faed (final turn on August 13, 2026)

Control task:

• 019ffa34-57ff-79c1-8167-969d55e50188

The control task used gpt-5.6-terra with high reasoning. It was a short task with no tool calls. When explicitly asked whether it could see the date instruction, it reported it once and did not loop. This indicates that merely receiving the date context is not sufficient; the failure appears associated with long tool continuations and/or the Sol model's handling of repeatedly supplied high-priority context.

What steps can reproduce the bug?

The issue is intermittent, but both affected tasks shared this pattern:

1. Sign in to Codex App using API login.
2. Select gpt-5.6-sol with high reasoning.
3. Run a long implementation task involving many tool calls, test commands, continuation messages, and a read-only reviewer/subagent wait.
4. Allow the same assistant turn to resume repeatedly after tool results or wait/poll operations.
5. Observe commentary after each continuation.

Actual behavior:

• The assistant begins explicitly acknowledging the current-date developer context without any date-related user request.
• It may say it will stop repeating the date, then repeats it again after the next tool continuation.
• The repetition can persist for many consecutive continuations.
• The assistant can subsequently lose the top-level user objective and adopt the role of the most recent internal subtask.

Concrete observations:

• In the first affected task, approximately 21 date-related acknowledgements appeared during implementation, testing, reviewer waiting, and commit stages.
• That task had no context compaction event, so compaction is not required to trigger the behavior.
• In the second affected task, eight consecutive date acknowledgements appeared while waiting for a read-only review result.
• After the reviewer was closed, the assistant returned a code-review report as the final answer instead of resuming the requested implementation workflow.
• The second task had an earlier compaction, but there was no new compaction when this final-turn loop began.
• Similar date acknowledgements had appeared in that older task on the previous day as well.

The rollout files do not appear to persist this date sentence as a standalone developer message. They persist turn_context.current_date, while the full high-priority date wording appears to be supplied by request assembly at generation time. This makes the behavior look like static high-priority context being treated as a newly arrived instruction on each tool continuation, rather than a user-visible message duplicated in the stored task history.

What is the expected behavior?

• Current date and timezone information should remain silent background context unless it is relevant to the user's request.
• Static developer context supplied on multiple continuations should not be interpreted as a new command that needs repeated acknowledgement.
• Tool results, reviewer waits, and continuation calls should preserve the top-level user objective.
• A temporary internal review subtask must not replace the assistant's main implementation role.
• The model should not enter a self-reinforcing acknowledgement loop based on its own previous commentary.

Additional information

This appears different from date/timezone correctness bugs: the date itself was correct. The problem is repeated explicit response to a static high-priority date instruction and the subsequent loss of task state.

It also does not require a compacted task: one affected task reproduced the issue without any context compaction. The strongest common factors observed were gpt-5.6-sol, high reasoning, a long tool-running turn, repeated generation continuations, and reviewer/wait polling.

A possible area to inspect is whether the request assembly/tool-continuation path re-presents static developer context in a form that the model treats as newly salient on every continuation. Once the first acknowledgement is written into task history, subsequent continuations may reinforce that local output pattern.

I can provide redacted rollout excerpts and exact record offsets privately if needed.