Find the evidence needed for recovery

Understand the approach

The source lesson opens a dedicated checkpoint browser. In Codex, begin with the evidence your client actually offers: saved chats, the review panel and the repository’s version history. The desktop app documents a review-tab shortcut, including Ctrl+Shift+G on Windows. The CLI /diff command displays working changes. Neither interface should be described as a browser of guaranteed automatic file snapshots.

A useful recovery inspection answers what changed, which files belong to the experiment, and which baseline you intend to restore. Git status distinguishes tracked edits and untracked files; a normal git diff does not display an untracked file’s content. Codex /diff is documented to include untracked files, but you should still inspect their paths and contents. Do not let a clean-looking partial diff hide a newly generated file.

A chat transcript adds intent and tool history, while repository history adds file versions. Compare both when a change appears unexpected. A commit timestamp alone does not prove that all relevant files were included. The linked Orbit Notes --git copy deliberately uses a staged index baseline and has no HEAD commit: inspect it with git show :README.md. In a different repository with a verified commit, git show HEAD:README.md and git log inspect that committed history instead. Record the actual baseline type rather than assuming those commands are interchangeable.

Read the index, worktree and untracked output separately

In this no-commit teaching repository, AM README.md means the file is added in the index and modified in the worktree. The untracked notes-draft.md appears as ??. git diff -- README.md compares the working candidate with the index; it does not include the draft’s contents. Open that file separately.

git show :README.md reads the staged version. git show HEAD:README.md cannot read a commit that does not exist here. The linked exercise records these real states and makes the baseline type explicit, so missing HEAD is understood rather than addressed through identity or remote changes.

When Git is unavailable

Use a separate known-good copy and compare the named file directly in an editor. Record that the exercise used a copy rather than pretending a commit exists. Do not install Git or alter global settings just to complete this inspection. The same reasoning applies: establish the source of the baseline, include newly created files in the inventory and preserve any work outside the experiment.

Try it step by step

1. Create the lab’s fresh Git-enabled copy from the course folder with node labs/project-workflow/create-workspace.cjs --git, if Git is already available; then open its returned path in Codex.
2. Run the read-only commands below inside that exact practice directory, and inspect untracked files separately.
3. Inspect the staged README baseline and current working file before proposing restoration; use a separate known-good copy if Git is unavailable.
4. Write a recovery note naming the target files, the index tree or recovery copy, preserved unrelated work, and the check to run afterward.

A useful starting example

Illustration · adapt before use.

git status --short
git diff -- README.md notes.cjs
git show :README.md

git log --oneline -5
git show HEAD:README.md

Check your result

• The evidence note includes tracked changes and any untracked output, without assuming git diff covers everything.
• The selected baseline contains the specific file version you intend to recover.
• The review interface is described by its observed behavior, not labelled a universal checkpoint browser.

Common mistakes

• Restoring files from the newest commit without checking whether that commit is the desired baseline.
• Equating a conversation timestamp with proof that the corresponding file version is available.