Over roughly the past two days, I’ve started seeing several problems across established tasks in one Codex engineering project. These tasks have defined responsibilities and normally send review requests to existing specialist tasks. This is a recent change in behavior for my workflow.
I’m using the Windows desktop app with GPT-6 Astra. I’ve been receiving app updates daily, sometimes twice a day, over the past week. I don’t know whether the problems are related to an app update, backend changes, the model, or several separate bugs.
1. Messages missing from the visible history inside an existing chat
On September 10, the visible history in my project-automation chat jumped from the previous night’s conversation to a message I sent at 10:59 a.m. Several earlier messages from that morning, including my first report about an unexpected new task and the assistant’s response, were absent.
This is not just a missing chat in the sidebar. I have an annotated screenshot showing the gap within the conversation. A read-only examination of the local session transcript subsequently found my missing report at 9:52 a.m. and the assistant’s reply at 9:53 a.m. Both precede the visible 10:59 a.m. message. So those messages exist locally, but were not appearing in the chat history I could see. All times here are Bangkok, UTC+7.
2. Tasks responding to old work instead of the current request
On September 9, a specialist task twice answered a completed converter-comparison question instead of the newer receiver/control review it had received. Local logs place those wrong-topic responses about 36 and 45 seconds after recorded context compactions. That is an observed sequence, not proof that compaction caused the problem.
Other review requests also needed reminders. The assistant’s task-history retrieval returned empty message lists for some completed turns and stale results for another, despite corresponding messages existing in local transcripts. These discrepancies have made coordination and checking what actually happened difficult.
3. “Another task” interpreted as permission to create a new chat
I found an unexpected “Dock Auto-Connect Review” chat, even though I already had “STM32 Debug & Power Dock” for that work. Local logs confirm that Board Design called the task-creation tool at about 9:56 p.m. on September 9.
For accuracy, my preceding instruction was: “We need another task to look at a proposed solution across all scenarios.” I meant another existing project task, not a newly created chat. Codex announced that it would create a separate task and then created it without asking me to clarify that distinction. Its generated assignment described me as having requested a separate task.
I regard this as an unwanted expansion of my request. I would like to understand how task-creation consent is supposed to work, and whether there is an enforceable way to require explicit permission for a new chat, rather than relying on the model to interpret “another task” correctly. I am not claiming to have proved a technical permission bypass.
I have preserved screenshots, timestamped local excerpts, the creation-tool record, and an incident record from September 9. The package captured that night was OpenAI.Codex_26.901.6511.0; the runtime reported codex-cli 0.153.4. That is the recorded incident environment, not a claimed last-known-good build or identification of the responsible update.
Has anyone else recently seen missing messages within a chat, stale responses after task handoffs or compaction, or unintended chat creation in a multi-task project? Is there a known issue, and what diagnostic information would help OpenAI investigate? I can provide reviewed excerpts and session identifiers privately if requested.
reaction to the GitHub issue itself, rather than only reacting to this forum topic. GitHub reactions can help the maintainers gauge how many users are affected.