Detect workspace drift before continuing stale plans

What feature would you like to see?

Codex should detect when the workspace has materially changed since the last state on which its current plan, analysis, or test conclusions were based.

Persistent threads can be resumed hours or days later, while users, other agents, CI systems, rebases, merges, generated files, or dependency updates may have changed the repository. Today, Codex can retain an old plan and continue as though the workspace were unchanged.

This creates a stale-context risk: Codex may edit the wrong branch, overwrite newer work, rely on files it previously inspected but which have since changed, or cite test results that no longer describe the current code.

This would complement elapsed-time awareness by checking actual project change rather than merely inferring that change may have occurred.

Example

1. Codex inspects feature/auth at commit a17c92f, reads auth.ts, and prepares a plan.
2. The thread is paused.
3. The user switches to main, another agent modifies auth.ts, and the lockfile changes.
4. The user resumes the thread and says: Implement the plan.

Codex should detect that the plan's trusted workspace state no longer matches the current workspace and revalidate affected assumptions before editing.

A possible user-facing summary:

Workspace drift detected since the previous trusted state:

- Branch changed: feature/auth -> main
- HEAD changed: a17c92f -> d09b34a
- 2 previously inspected files changed
- package-lock.json changed
- Previous test result is now stale

I will re-read the affected files before applying the previous plan.

Proposed behaviour

Codex should maintain a lightweight trusted workspace state associated with a thread or plan. It could include, where available:

• repository identity and working directory;
• branch and HEAD commit;
• relevant working-tree status;
• hashes or metadata for files Codex read, modified, or based decisions on;
• relevant manifests and lockfiles;
• commands and test results used as evidence;
• timestamp of the trusted state.

Before executing a resumed or previously prepared plan, Codex should compare the current workspace with that trusted state and classify drift.

Suggested classifications:

• none: no material change;
• informational: unrelated files changed;
• relevant: observed files, dependencies, generated outputs, or assumptions changed;
• critical: branch, repository, base commit, or files targeted for modification changed.

Safeguards and scope

• This should not hash or rescan the entire repository on every turn.
• Track primarily the files and repository facts that the current analysis actually depended on.
• Treat file watches and Git metadata as signals, not absolute truth.
• Do not block all work because of unrelated changes.
• Re-read and revalidate only the affected parts when possible.
• Do not overwrite unrelated user changes while reconciling drift.
• Work in repositories without Git by using file metadata or content hashes where practical.
• Refresh the trusted state after successful revalidation, compaction, rollback, fork, branch switch, or worktree change.
• Surface uncertainty when the previous state cannot be reconstructed reliably.

Why this is useful

This would reduce several common failure modes in persistent and multi-agent development:

• applying a stale plan after a branch switch or rebase;
• modifying files that changed externally since inspection;
• treating old passing tests as current evidence;
• losing track of changes made by another agent or editor;
• assuming dependencies or generated artifacts are unchanged;
• continuing in a different repository or worktree without noticing.

The underlying concept is similar to optimistic concurrency control, but applied to an agent's analysis and execution state.

Suggested acceptance criteria

• Resuming a thread after HEAD changes makes the change visible to Codex.
• A previously inspected target file changing causes reinspection before modification.
• Unrelated file changes do not unnecessarily block the task.
• A branch or worktree change is treated as high-severity drift.
• Previous test results are marked stale when relevant code or dependencies changed.
• Drift detection survives compaction and thread resume.
• The behaviour works consistently across CLI, Desktop, VS Code, app-server, and parallel-agent workflows.
• The user can inspect why Codex considered a prior plan stale.

Related feature

This is complementary to #36713, which proposes elapsed-time awareness between user turns. Time awareness indicates that change may have happened; workspace-drift awareness determines whether relevant change actually happened.