Day 13 of 21
When Codex goes wrong - the exact recovery process
Goal: Learn what to do the moment something breaks: stop immediately, collect the right information, build a recovery summary, use GitHub Desktop to undo safely, and know exactly when to stop trying to fix and start fresh.
What to do
Stop immediately — do not run another command
The moment something looks wrong, stop typing. Do not run another Codex prompt. Do not press Enter on anything. Do not close the terminal. Every new command you run before understanding the problem makes diagnosis harder and recovery more complicated. Take a breath. The project is not permanently broken. Your only job right now is to stop and assess.
Copy the exact error and write a recovery summary
Save the exact error text first — all of it, including the parts that look like jargon. Then fill in the recovery summary template below. This template is designed to give you — and Codex — everything needed to understand and fix the problem without having to guess. Fill in every field before taking any action.
Recovery summary — fill this in before doing anything else:
Error text (exact copy): [PASTE THE FULL ERROR]
Last Codex action before the break: [DESCRIBE WHAT CODEX DID LAST]
Files changed in this session (from GitHub Desktop): [LIST THEM]
Was this working before this session, yes / no
What I was trying to do: [DESCRIBE YOUR TASK IN ONE SENTENCE]
My decision: revert / investigate more / ask Codex to explain without fixingCheck changed files and match them to the error
Open GitHub Desktop and look at the list of changed files in the left panel. Compare that list to your recovery summary. The question you are trying to answer is: does the error make sense given which files changed, A "file not found" error when Codex created a new file may mean the file has the wrong name. A "syntax error" after Codex edited a file means the edit introduced a typo or broken code in that file.
Know when to stop trying and start fresh
There is a point where trying to fix a broken state becomes more damaging than simply reverting to the last working commit. Stop trying to fix and start fresh when: you have run more than two fix attempts and the error is still there, you do not understand what Codex changed or why, or you feel like you are guessing. Reverting is not failure — it is good engineering. Use GitHub Desktop to revert to your last commit on this branch.
How to revert to the last clean state in GitHub Desktop:
1. Open GitHub Desktop
2. Click "History" in the left panel
3. Find the last commit where everything was working
4. Right-click that commit and choose "Revert Changes in Commit"
(this creates a new commit that undoes the changes)
5. Alternatively: for uncommitted changes, right-click each changed file
and choose "Discard Changes" to remove them entirely
After reverting, your project is back to the last working state.
Start the next session with a smaller, more specific task.Commit only after verifying the fix works
Once the project is working again — either through a targeted fix or a revert — verify it works before committing. Open your project in a browser if it is a website. Check the specific thing that was broken. Check one or two other things that were working before, just to confirm nothing adjacent broke. Only when the project feels stable should you commit with a clear message describing what happened and what you did.
Expected result
You stopped immediately when something broke, saved a complete recovery summary, checked GitHub Desktop to identify the responsible files, used the revert or discard tools to get back to a clean state, verified the fix before committing, and know the rule for when to stop fixing and start fresh.
Key takeaway
- When Codex breaks something: stop, collect, assess, revert if unsure. Two failed fix attempts is the limit — if the error is still there after two tries, revert and start fresh. Stacking fixes on a broken state makes everything harder to understand and harder to undo.