Codex agent loses track of the active request and performs unrelated actions

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

Version 26.602.40724 • Released Jun 5, 2026

What subscription do you have?

200$

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

During a Codex desktop session, the assistant repeatedly lost track of the current user request and acted on a previous topic. The active task was to improve a paywall / Studio Pass CTA in an iOS app, but the agent instead modified notification settings from an earlier request. When the user objected, the agent misread the objection again and reverted the notification change, even though that change was actually desired. The user then had to correct the agent a second time.

This looks like a failure to anchor actions to the latest user instruction before performing code edits and git operations.

What steps can reproduce the bug?

1. Work in a long Codex desktop thread with several recent code-change requests.
2. Ask Codex to make a specific change in one area of the app.
3. Then ask for a different change in another area, with a screenshot and context.
4. Observe Codex act on the previous topic instead of the latest request.
5. Tell Codex that it acted on the wrong request.
6. Observe Codex incorrectly assume the latest commit should be reverted, instead of re-reading the active request or asking for clarification.

What is the expected behavior?

Codex should anchor every tool action and code edit to the latest user message. If the user complains that the agent acted on the wrong thing, Codex should pause, re-read the current request, and ask for clarification if needed. It should not automatically revert a commit unless the user explicitly asks for a revert.

Additional information

This happened in a private iOS app repo while using the Codex desktop app. The failure caused unrelated code edits and extra revert/reapply commits. It seems related to request anchoring across adjacent tasks, interruption handling, and over-eager corrective actions after user feedback. The practical impact is loss of trust and unnecessary Git history churn.