Where Claude Code saves its plan file, and how to read it without an IDE
Bobby Huang ·
Find the path the agent gave you, then open the file in something light. In a terminal, less shows it page by page. A plain text editor works too, and a Markdown viewer shows it rendered. Read the goal and open questions first, then the steps. Check scope, files touched, anything that deletes data, and how the work will be tested. If the agent revises the plan, compare it with your last copy instead of reading it again.
Key takeaways
- You do not need an IDE to review a plan. A terminal pager, a text editor or a Markdown viewer is enough.
- Read the goal and open questions before the step list. A wrong goal makes every step wrong.
- Check four things in every plan, namely scope, files touched, destructive steps and tests.
- Keep a copy of the plan you approved, so you can diff it when the agent revises it.
- Skimmark is a Markdown reader in development for this kind of file. Its features are planned for v1.
Claude Code can write its plan to a Markdown file before it starts work. That is a good habit. A plan on disk is something you can read, question and keep. But opening a full IDE just to read one .md file is slow, and it pulls you into the code before you have agreed on the plan.
This how-to covers light ways to read a plan file, what to look for, and how to keep up when the plan changes. It is part of a series on reviewing the Markdown your AI agents write.
Step 1: Find the file
By default, Claude Code keeps the plan files it writes in plan mode in ~/.claude/plans/, inside your home folder, not your project. A plansDirectory setting can move them into the project instead (per the Claude Code settings docs, checked October 2026).
Start with the path Claude Code gave you. If you don't have it, ask: "What is the absolute path of the current plan file? Confirm that it exists." If no file was saved, ask it to save the plan as Markdown and return the path. Open that exact file.
Step 2: Open it in something light
Pick the lightest tool that fits how you work:
- Terminal, raw text.
less plan.mdshows the file one page at a time. Press/to search andqto quit.cat plan.mdprints it all at once. - Text editor. Any plain text editor opens a
.mdfile. You see the raw Markdown, which is fine for short plans. - Markdown viewer. A viewer shows the plan rendered, with real headings, tables and check-boxes. Long plans are easier to skim this way.
Raw text is fine for a quick look. For a long plan with tables or task lists, a rendered view saves effort. The review guide covers when to use each.
Step 3: Read in the right order
Do not start at step one of the plan. Start with what decides whether the steps matter.
- The header. If the file starts with a YAML block between
---lines, read its status and date. - The goal. Does it match what you asked for? If not, stop here.
- Open questions or assumptions. Answer them now. An assumption you skip becomes a step you undo.
- The steps. Read them last, with the goal in mind.
Step 4: Check four things
Every plan deserves these four checks before you say yes:
- Scope. Is it doing more than you asked? Extra work is extra risk.
- Files touched. Does the list of files match the goal? A surprise file is worth a question.
- Destructive steps. Any step that deletes, overwrites, resets or migrates data needs a clear reason and a way back.
- Tests. How will you both know it worked? A plan with no check at the end has no finish line.
If the plan uses check-box tasks, - [ ] for open and - [x] for done, you can use them to track your review. Tick a step once you have confirmed it, not once the agent says so.
Step 5: Follow the plan as it changes
Plans get revised. You ask a question, and the agent rewrites the file. Reading the whole thing again wastes the time you saved by planning.
Keep a copy of the version you approved:
- Before you reply, run
cp plan.md plan.approved.md. - After the agent revises it, run
diff plan.approved.md plan.md. - If the project uses git,
git diff -- plan.mddoes the same job.
Now you only read what moved. If the change is small, approve it and copy again. If it is large, go back to step 3.
Step 6: Fix small mistakes yourself
Sometimes one line is wrong. A file path has a typo, or a step is in the wrong order. You can fix it yourself and tell the agent.
Make the fix in a way that changes only that line. Some editors reformat the whole file on save. Then the agent sees a large diff and has to work out which change was yours. A one-line fix should look like a one-line change.
The same habits apply to the other files agents leave behind, such as handoff files.
Where Skimmark fits
Skimmark is a small, fast Markdown reader and editor for people whose AI agents write Markdown. It is in development and has not been released. It is designed for this exact job. Planned for v1:
- Open a file from the terminal with the
skimmarkCommand. - Live Reload that updates the page when the agent rewrites the plan, and keeps your Reading Position.
- A Changes View that shows what changed since you last marked the file as seen, with no git needed.
- Edit a line on the rendered page and save without changing the lines you did not touch.
The app itself has no AI features. Claude Code writes the plan. Skimmark is planned as the place you read it.
See what Skimmark is and follow along at skimmark.com.
Questions
- Where does Claude Code save its plan?
- By default, plans written in plan mode go to ~/.claude/plans in your home folder, unless the plansDirectory setting points somewhere in your project. To be sure, ask Claude Code for the absolute path of the current plan file and confirmation that it exists. If the plan hasn't been saved, ask it to save a Markdown copy and return its path. Use that path rather than guessing from file names.
- Can I read a Markdown file in the terminal?
- Yes. less shows the raw text one page at a time, and cat prints the whole file. Both show the Markdown as plain text, not rendered.
- What should I check before I approve an agent's plan?
- The goal, the scope, the files it will touch, any step that deletes or overwrites data, and how the work will be tested. Then read the open questions and answer them.