Feature: File-level Local History in the Codex file viewer

Problem

Codex already has a strong understanding of changes it makes to a repository. However, the available change/revert concepts are primarily centered around a Codex turn or task.

For day-to-day development, the unit of recovery often needs to be a single file, not a Codex turn.

Example:

1. Codex modifies 12 files as part of one task.
2. The resulting state is good.
3. Later, one of those files is accidentally modified in an editor, by another tool, or during another Codex interaction.
4. I want to restore only that file to its earlier state.
5. The other 11 files must remain untouched.

Git is not a good replacement for this because the interesting state may never have been committed.

This is the role that Local History provides in IntelliJ-based IDEs, and it becomes even more useful in an agentic development workflow.

Proposal: Local History in the Codex file viewer

Add a History view for individual files in the Codex file viewer.

For example:

HarpnotesLayout.ts

History

12:41  External change
       +3 -4
       [Diff] [Restore]

12:32  Codex
       "Fix countnote collision handling"
       +18 -5
       Tests passed
       [Diff] [Restore]

12:18  Codex
       "Refactor voice positioning"
       +31 -10
       Tests failed
       [Diff] [Restore]

11:57  Git commit 3ac8e21
       "Improve harpnotes layout"
       CI passed
       [Diff] [Restore]

Selecting a revision should allow:

• viewing the file as it existed at that point;
• diffing it against the previous revision;
• diffing it against the current version;
• restoring only this file to that revision.

Restoring a file must not revert other files that happened to be changed by the same Codex turn.

External changes are important

The history should not be limited to modifications made directly by Codex.

Changes made by an editor, formatter, script, Git operation, or another tool should also create revisions.

This covers an important recovery case:

I accidentally edited or overwrote a file in my editor. Show me how this file looked before that happened.

Codex-generated revisions can have richer metadata, while externally generated revisions can simply be identified as external changes.

Codex can make Local History more useful than traditional IDE Local History

For changes made by Codex, the history can record why a revision exists:

• Codex turn / prompt
• files changed in that turn
• test result after the change

The history could later also correlate revisions with repository information such as:

• included in Git commit abc123
• pushed to a remote
• CI passed/failed
• included in a deployment

These states should be presented as information about the repository state containing that file revision, rather than implying that a single file itself was independently tested or deployed.

This would turn Local History into both a recovery mechanism and a useful development history.

Relationship to checkpoint / rewind requests

This is related to existing requests for Codex checkpoints and rewind, but it solves a different problem.

A checkpoint answers:

"Restore the workspace to the state before/after this Codex turn."

File Local History answers:

"Show me the history of this particular file and restore only this file to a previous state."

Both are useful, but one cannot replace the other.

A Codex turn may modify many files, and subsequent manual or external changes may affect only one of them. In that situation, reverting the entire turn is too coarse.

Related requests include #11626 and #12558.

Minimum viable version

The first version does not need CI or deployment integration.

The essential functionality would be:

1. Automatically retain revisions of files changed in the working directory.
2. Expose those revisions from the Codex file viewer.
3. Show a diff for each revision.
4. Restore a selected revision of one file without affecting any other file.
5. Distinguish Codex changes from external changes where possible.

Codex-turn metadata, test results, commits, CI and deployment information can then enrich the history incrementally.

The important property is that this works automatically. Like IDE Local History, developers should not have to remember to create a snapshot or Git commit before discovering that they need an earlier version.

No implementation files or tests are named. Start by locating the Codex file viewer and existing checkpoint or rewind handling, then trace how workspace changes are recorded. Done means an MVP that automatically retains file revisions, exposes them in the viewer, supports per-file diffs and restoration, and distinguishes Codex from external changes where possible.