Stale assistant reply after tool error ignores latest request #14253
Description
What version of Codex CLI is running?
codex-cli 0.111.0
What subscription do you have?
ChatGPT Pro
Which model were you using?
gpt-5.4-xhigh
What platform is your computer?
Linux 6.17.0-14-generic x86_64 unknown
What terminal emulator and version are you using (if applicable)?
Blink + tmux
What issue are you seeing?
Codex sometimes emits a stale prior response after beginning tool work for a newer user request.
In my session, I gave a new instruction to open a Step + PR, implement a fix, run the full Greptile loop, merge it, and then progress a Step in the
app. Codex acknowledged the request, updated its plan, and started tool work.
During that work, one tool call failed with:
ERROR: column "source" does not exist
LINE 1: ...type, aggregate_key, from_state, to_state, event, source, tr...
^
After that tool error, Codex did not continue the latest task. Instead, it returned an older explanatory response about PR #1037, which was from the prior context and did not address the current request.
This happened in a long-running coding session and has occurred more than once. It looks like stale response replay or bad recovery after a tool error / context transition.
Relevant stale response it emitted instead of continuing the new request:
#1037 fixed the entry condition, not the completion condition.
What it fixed:
- When Greptile leaves a fresh current-head review, Journey now starts the first review_fix run instead of holding in awaiting_post_review_fix_commit.
- That is why run 1117 started at all.
...
What it did not fix:
- After a successful review_fix pushes a new commit, Journey still fails to trigger the next Greptile rereview.
...
That response was not the task I had just asked it to perform.
What steps can reproduce the bug?
Uploaded thread: 019c48d0-8905-7c31-bb73-858512000eea
High-level repro pattern from this thread:
- Have a long-running coding session with multiple related subtasks.
- Give Codex a new instruction that changes the task materially.
- Codex acknowledges the new task, updates its plan, and starts tool calls.
- One of the tool calls fails.
- Instead of recovering and continuing the newest request, Codex emits a stale response from the previous topic/context.
The concrete tool failure in this session was:
ERROR: column "source" does not exist
LINE 1: ...type, aggregate_key, from_state, to_state, event, source, tr...
^
Immediately after that, Codex emitted a stale explanatory answer about PR #1037 rather than continuing the new request it had just acknowledged.
I am referencing the uploaded thread rather than duplicating the full transcript here.
What is the expected behavior?
After a tool error, Codex should do one of these:
- Recover and continue the latest user request, or
- Explicitly say that the tool error blocked progress on the latest request.
It should not emit a stale prior response that ignores the current instruction.
In this case, after the SQL query failed, the expected behavior was to keep executing the newly requested task (open the Step + PR, implement the fix, run the review loop, merge it, and progress the Step) or clearly state that the failed query blocked that work.
Additional information
- This happened in a long-running coding session with many tool calls and several context shifts.
- I have seen this behavior multiple times in the same session.
- It feels like stale draft replay, failed tool-error recovery, or bad context resume behavior.
- The bug is especially costly in autonomous coding sessions because it looks like the assistant is ignoring the latest instruction while pretending to continue working.
- I did express frustration in the thread; that is part of the authentic transcript and should not affect bug triage.