Static reading edition · s08-01
Know what a checkpoint actually protects
Separate conversation recovery, local file recovery and external side effects before experimenting.
Understand the approach
A checkpoint is useful only when you know which state it captures. The Claude source describes automatic snapshots with a dedicated rewind interface. Do not transfer that promise to Codex. In Codex, a saved chat preserves conversation history, a Git commit preserves selected repository files, and a backup preserves whichever files were actually copied. These mechanisms overlap only partly and must be evaluated separately.
Before a change, identify three state boundaries: the chat, the working files and external systems. Starting or forking a chat can change the conversation context without reverting files. Restoring a file through Git does not erase the conversation that discussed it. An email, published release or database change cannot be undone merely by returning to an earlier chat message. Plan recovery around the actual resource being changed.
The official CLI guide recommends Git checkpoints before and after tasks. In a practice project, inspect the starting state, preserve unrelated work and use a small baseline commit or separate copy. Record the command needed to check behavior. This makes experimentation measurable: you can compare the baseline and candidate, rather than relying on a vague recollection that the project seemed to work before.
Different kinds of state need different recovery
Saved chat history helps recover conversation context. A Git baseline or a verified copy helps restore files. External side effects require the affected service's recovery procedure. Recovering one kind does not automatically undo the others.
Name the protected content before experimenting
The supplied starter copy is a concrete baseline: you can open it and compare the candidate. An optional staged Git tree protects eight named starter paths for this exercise. Neither is an automatic Codex snapshot of the conversation, machine, ignored files or external services.
Use the recovery guide to make a deliberate heading experiment, then inspect the resulting file. A new chat changes context; it does not restore the heading. The useful later paragraph in the next exercise makes whole-file restoration an observable loss counterexample.
Small experiments reduce recovery cost
A focused change to one document is a better first exercise than a broad refactor. Keep generated files, local configuration and external actions outside the initial experiment. If the task later needs a database migration or publication, design a separate recovery procedure for that system. A checkpoint label is not a guarantee of transactional rollback across every connected tool.
About your environment
Checked 21 October 2026. Feature availability varies by client and host.
Try it step by step
- Choose one harmless local task and list the conversation, files and external resources it might affect.
- Inspect existing changes, then make a baseline commit or separate copy only after identifying the intended files.
- Record a small behavior check and its starting result before asking Codex to make the experimental change.
- Inspect the candidate and decide whether to keep, refine or restore the affected files using the recorded baseline.
A useful starting example
Illustration · adapt before use.
Before changing this scratch project, inspect its current state and identify unrelated edits. Explain what protects the chat history, the files and any external state. Propose a small file baseline and a behavior check. Do not claim a chat fork restores files, and do not run a destructive reset or contact external services.Identify what the baseline captures
The capstone verifier performs this local fixture sequence in fresh temporary directories.
Starter files → known copy
Run six checks → 4 pass / 2 fail
Apply reference → 6 pass / 0 fail
External services → none usedThe file copy protects the supplied starter.
A chat transcript is separate.
No remote rollback is demonstrated or needed.The baseline is an inspectable copy, or an optional Git index tree. It is not labelled an automatic Codex checkpoint or a complete machine snapshot.
Your turn
Create a fresh practice copy and record its actual path and baseline check. Change only the README heading in that copy, keeping the original starter untouched. Identify how you would recover the file and where conversation history lives. Explain what this copy does not capture: later untracked files and any external system.
Try the exercise before opening its reference answer. Use a disposable practice folder.
Orbit Notes project and recovery capstone
Extract into a new practice folder and keep the included labs folder. Run these commands from that extraction root, or from the course folder, using an existing Node.js installation.
- Command 1 text
node labs/project-workflow/create-workspace.cjsCheck: Returns a new owned temporary path. Open that exact copy in the app; the shipped starter stays broken.
- Command 2 text
node labs/project-workflow/verify-depth.cjsCheck: Runs two candidate implementations and recovery counterexamples in fresh copies. Reports paths, facts and preservation; live skill/instruction discovery remains a separate observation.
Follow this lesson’s specific walkthrough and compare its result with the answer key. Commands are relative to the course folder. The offline demonstration never claims a live Codex client loaded instructions, selected a skill or retrieved a connected record.
Check your result
- You can name exactly what the baseline captures and which untracked or external data it does not protect.
- A behavior or content check exists before the experiment, so the candidate can be compared meaningfully.
- The recovered file matches the baseline and unrelated work remains intact.
Reference answer & rubric Try the exercise before opening
Name each protected state and prove the local baseline before allowing the experiment.
- Create a fresh copy and inspect the ownership marker and source files.
- Run the baseline checks and retain the expected two failures.
- Record which files the copy or index protects and what remains outside it.
- Compare the actual result with the lesson-specific answer key; record unrun client observations separately from executed local checks.
Check your understanding
Forking a chat is sufficient to undo which of these automatically?
- Every file written after the fork point.
- A message already sent to an external service.
- Neither; conversation branching alone establishes no file or external rollback.
Reveal the answer and explanation
Answer 3: Neither; conversation branching alone establishes no file or external rollback.
A fork copies conversation history. File and external-state recovery require their own verified mechanisms.
Take this quiz in the interactive lesson to save your answer in the browser.
When it does not work
A supposedly safe restore loses unrelated work.
Likely cause: The baseline scope or later edits were not inventoried.
What to try: Compare named files and preserve unrelated content before recovery.
The baseline test result is described as a passing project.
Likely cause: Intentional exercise failures were hidden.
What to try: Record 4 pass and 2 fail explicitly; use the reference only as a comparison.
Common mistakes
- Treating a saved chat as a complete filesystem snapshot with universal undo.
- Starting an experiment before checking whether another person already has uncommitted changes in the project.
Source mapping & differences · alternative
Codex is taught through explicit Git/file baselines and saved chats, rather than promising the Claude automatic checkpoint-and-rewind system or its retention behavior.
Source topic: Overview ↗Go to the source
Official documentation, checked 21 October 2026. Product names, controls and availability may vary with your version, platform or account.
Completion and quiz progress are saved
only in the interactive course.