Repository navigation
[Bug] Inter-agent message can cause Codex to resurrect and answer an old user prompt #45894
Description
Summary
In a long-running Codex conversation that uses other Codex agents/subagents to send updates back to the main thread, receiving a new inter-agent message can cause the main Codex to respond to a much older user message instead of the newly received agent update/current task state.
The old user message had already been handled earlier in the conversation. When this happens, the new response is visibly unrelated to the current point in the workflow.
This appears more specific than a general "responds to an older message" problem because the recurring trigger observed here is a message/update arriving from another Codex agent/subagent.
Reproduction pattern
- User sends message A to the main Codex thread.
- Codex handles message A normally.
- Many additional turns and task work happen afterward.
- Another Codex agent/subagent sends a new progress/update message to the main thread.
- The main Codex wakes up, but instead of processing that new inter-agent message/current context, it responds again to old message A.
- The same stale-message behavior can recur after later agent-to-agent updates.
Expected behavior
A newly received inter-agent message should be processed as the latest relevant event in the current thread state. Codex should continue from the current task/context and should not treat an already-completed historical user prompt as if it had just been received again.
Actual behavior
After an inter-agent update arrives, the main Codex can resurrect and answer an older user prompt that was already completed much earlier in the thread.
Impact
- Breaks multi-agent orchestration workflows.
- Produces duplicate or unrelated work.
- Wastes tokens/time.
- Can be risky if stale instructions cause old code changes or operations to be repeated.
- Makes it hard to trust agent-to-agent handoffs in long-running threads.
Suspected failure boundary
Not claiming a confirmed root cause, but the symptom looks consistent with a problem in one of these areas:
- ordering/injection of inter-agent messages versus historical user turns;
- active-turn/task pointer restoration;
- thread/context reconstruction after an agent update;
- stale task state being selected when the parent thread wakes.
The key observation is that agent-to-agent delivery appears to be the trigger, not simply a user sending another normal message.
Related issues
Possibly related, but not necessarily duplicates:
- Codex replies to earlier messages instead of latest one in conversations #8648 — Codex replies to earlier messages instead of the latest one in conversations.
- Windows Desktop: scheduled heartbeat answers an older request in a long thread; user also reports UI lag #43632 — scheduled heartbeat in a long thread answers an older request.
- [Bug] Experimental context compaction can resurrect a stale task and lose the current request #45464 — context compaction can resurrect a stale task.
This report adds a narrower and repeatedly observed trigger: a new message from another Codex agent/subagent causes the parent/main thread to answer an old human user prompt instead of the new agent message.
Diagnostics
An in-app feedback report with diagnostic logs was submitted for the affected incident.
In-app Feedback ID: 01a093e9-fc95-7a51-8199-c56b25aef09e
A screenshot of the incident is available. In the visible conversation, Codex itself acknowledges that it mixed up the context and responded to an earlier problem after receiving new progress from another agent.
Environment
Exact Codex app version/model build was not captured in this report. The issue was observed in the Codex app during a long-running multi-agent workflow.
If useful, the diagnostic upload associated with the Feedback ID above should contain the exact thread/runtime information needed to inspect message ordering.
Activity
github-actions commentedon Sep 16, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
q723499747-jpg commentedon Sep 16, 2026
Additional environment details from the affected setup:
26.908.70816This is the app/version where the inter-agent stale-prompt behavior was observed.
q723499747-jpg commentedon Sep 16, 2026
Additional environment detail from the affected session:
Screenshot available from the user if needed.
RongNianXin commentedon Sep 17, 2026
I observed a related Windows case that adds a concrete side effect to this report.
A teaching task had already completed in a projectless environment. After the parent thread received an unrelated inter-agent request, a context compaction occurred. On recovery, with no new request to repeat the teaching task, the parent issued another
create_threadcall for the old teaching objective. The second call targeted this repository as an isolated worktree, whereas the original task was projectless.The original projectless teaching task remained available. The visible symptom was that the new inter-agent request was not handled; the parent instead resumed the completed historical objective and attempted task creation again.
This is an observed sequence, not a confirmed root cause. I do not have the pre/post-compaction model input, compaction summary, or host routing logs, so I cannot tell whether the failure is in model state interpretation, client/context reconstruction, or both.
Expected behavior: once a task has completed and its result has been delivered, it must not become actionable again after compaction. Before
create_threadis called, the parent should re-check the latest event, the normalized objective, the requested delivery type, and any existing completion record.A redacted timeline and screenshot are available if they would help with diagnosis.
RongNianXin commentedon Oct 7, 2026
Additional Windows observation: current work and a cross-thread reply succeeded, but the local final answer addressed an older task.
Unlike my earlier occurrence reported in this thread, the receiving thread completed the current delegated work and sent a relevant result back to the sender. Its final answer to the operator still led with an older, already-completed topic. A short summary of the current task appeared only at the end.
The inspected turn records this sequence:
The operator pointed out the mismatch. A subsequent readback confirmed that the current artifacts and source reply were correct; the local final report had selected the wrong primary topic.
This overlaps with #42695 rather than establishing a new underlying bug. The useful distinction is that successful execution, a matching source reply, and a nonempty final answer can all coexist with stale-topic reporting. A regression test should check whether the local final answer addresses the active objective, in addition to verifying execution and the cross-thread reply.
Windows installed package version checked afterward: 26.928.3736.0. The About-dialog version, incident CLI/model build, exact inference inputs, and compaction-summary contents were not verified. Compaction precedes the mismatch, but a shared underlying cause is unconfirmed.
No private prompts, project details, account information, task identifiers, local paths, screenshots, or raw logs are included.
RongNianXin commentedon Oct 10, 2026
Additional evidence: stale prior-turn final answer after an ordinary new user message
Summary
In a long-running Codex Desktop conversation, a new ordinary user message asked for diagnosis of a cross-task dialogue routing failure. The immediately preceding visible turn had completed a remote update/synchronization request. The current turn began with the correct topic and a read-only history inspection, but the final answer reported the previous remote synchronization result instead of addressing the current request.
This is a persisted wrong-topic final answer, not merely a display mismatch. The current turn had no visible remote synchronization write/tool call. The earlier synchronization conclusion was reused as if it were evidence for the new request.
Expected behavior
The final response must be bound to the current user message and current-turn actions. A previous success, merge, or synchronization conclusion must remain historical evidence and must not close a later request. If the runtime cannot establish which request a candidate answer belongs to, it should return an explicit unverified/error state or ask for clarification, and must not repeat side effects.
Observed sequence (sanitized)
Evidence boundary
The local transcript exposes user/assistant turn boundaries and visible tool activity. It does not expose the complete model input, host event stream, hidden continuation state, or any opaque compaction payload. This report does not claim that compaction or networking is the unique cause. It asks maintainers to investigate stale final selection, turn/task pointer restoration, delayed result association, and multi-agent or cross-task routing state.
Related reports
RongNianXin commentedon Oct 10, 2026
Additional Windows reproduction: the cross-task message arrived, but the final answer still used the previous task.
The incoming message was visible as a functionCallOutput containing a <codex_delegation> payload with the source task and full request. The receiving task initially acknowledged the message, but its final answer answered an older task instead of the current cross-task request.
This is not a transport-loss case. It appears to be a stale final-output or request-binding failure after successful inbound delivery. Existing workflow checks passed, but they are static contracts and cannot inspect the host event stream or force runtime output ownership.
Environment:
Expected: the latest inbound event must replace the previous task as the active request, and the final answer must be checked against that event before closeout.