--- title: Keep your place while your AI agent rewrites the file slug: keep-your-place-while-your-agent-rewrites-the-file excerpt: When an agent rewrites a Markdown file you are reading, some apps jump to the top and others show a stale copy. Anchor on headings and save a "seen" copy. quickAnswer: You can lose your place when an app reloads and jumps to the top, or miss the change when it does not reload and leaves you on a stale copy. Line numbers also shift when the agent inserts lines above you. Anchor on the heading you were reading, not the line number. Save a "seen" copy of the file each time you finish reading, then diff the new version against it so you only read what changed. For a file the agent is still writing, wait for the status field to say it is done, read top-down, and re-check the header after every reload. keyTakeaways: - Apps handle a changed file in different ways. Some reload and jump to the top, and some never reload, so you read an old copy. - Line numbers move when the agent adds lines above you. A heading is a steadier bookmark. - A "seen" copy of the file lets your next look show only what changed since you last read it. - On Mac or Linux, two shell commands, cp and diff -u, give you a "seen" copy today with no extra tools. - Ask the agent to append and keep headings stable, so your bookmark survives the next rewrite. publishedDate: 2026-10-19 dateModified: 2026-10-19 author: Bobby Huang cluster: A role: post status: published faq: - q: What is markdown live reload? a: Live reload means the app notices the file changed on disk and shows the new version without you reopening it. It helps only if the app also keeps your place. A reload that drops you at the top makes you scroll back and guess where you were. - q: Why not just bookmark a line number? a: Line numbers belong to one version of the file. If the agent adds ten lines above you, line 120 now points at different text. A heading moves with its section, so it still points at the right place after the rewrite. - q: Do I need git to keep a seen copy? a: No. Copying the file aside with cp works in any Mac or Linux terminal, and on Windows through WSL. If the folder is already in git, a commit does the same job and keeps a history too. related: - how-to-review-markdown-your-ai-agents-write - see-what-changed-in-a-markdown-file - how-to-diff-markdown-files-with-git --- You're halfway down a plan file. Your agent saves a new version. Depending on the app, you may land back at the top of the page, or keep reading the old text without knowing it. Neither is a crash. Both cost you minutes, and they add up across a day of agent work. This page is about that moment. It covers why your place gets lost, how to mark a file as read so the next look shows only what's new, and a routine for reading a file the agent is still writing. It's part of a series on [reviewing the Markdown your AI agents write](how-to-review-markdown-your-ai-agents-write.md). ## Why you lose your place A Markdown app has to decide what to do when the file on disk changes under it. Some apps handle this well. Others fail in one of two ways. **It reloads and jumps.** The app sees the change, re-renders the whole page and starts you at the top. The content is fresh, but your position is gone. You scroll, skim and try to find the paragraph you were on. **It doesn't reload.** The app keeps showing the version it opened. You read on, and everything looks normal. But the agent changed the status two minutes ago, or rewrote the step you're checking. You're reviewing text that no longer exists. The second failure is worse because it's silent. A jump at least tells you something changed. A stale copy tells you nothing. Some editors ask before reloading. That's safer than a silent stale copy, but it still interrupts you, and after you say yes you may land at the top anyway. ## Why line numbers make a bad bookmark The obvious fix is to remember a line number. "I was at line 140." It breaks as soon as the agent adds anything above you. Say the agent adds three open questions near the top and a new step in the middle. Every line below those additions moves down. Line 140 is now some other sentence, maybe in a different section. If you jump there, you start reading in the wrong place and may not notice. Headings hold up better. A heading like "## Steps" or "## Open questions" moves with its section. If the agent inserts lines above it, the heading moves down too, and it still sits on top of the text you were reading. If you search for the heading text, you land in the right section after any rewrite that kept it. So the habit is simple: when you stop reading, note the heading you were under, not the line. If you were deep in a long section, note the first few words of the paragraph too. Search for those after the reload. This only works if the agent leaves headings alone. A rewrite that renames "Steps" to "Plan" breaks your bookmark the same way inserted lines break a line number. That's why the prompt further down asks the agent to keep headings stable. A good reader should reload in place and keep you on the same heading after the agent saves. Sashmark is being built for this; the [roadmap](/roadmap) shows where it stands. ## Mark a file as read with a "seen" snapshot Keeping your place helps with the next minute, and a "seen" copy helps with the next hour. The idea: each time you finish reading a file, save a copy of it as it was. That copy is your "seen" version. Next time you come back, you don't re-read the file. You compare the current file against the seen copy and read only the difference. When you've read that, you update the seen copy and you're current again. This changes what a review costs. A file that grew from 80 lines to 200 over an afternoon might have only 30 lines that matter since you last looked. You read the 30. ### A seen copy with cp and diff You can do this today with two standard commands in a Mac or Linux terminal (on Windows, use WSL). The paths below are samples; swap in your own. ```sh # After you finish reading: save what you saw. mkdir -p ~/.seen cp ~/work/doe-holdings/plan.md ~/.seen/plan.md # Next time: show only what changed since that copy. diff -u ~/.seen/plan.md ~/work/doe-holdings/plan.md # Once you've read the changes, mark it seen again. cp ~/work/doe-holdings/plan.md ~/.seen/plan.md ``` `diff -u` starts with two header lines that name the files, then prints the changed lines with a little context around them. Below the headers, lines starting with `-` were in your seen copy and lines starting with `+` are new. If it prints nothing and shows no error, the file has not changed since you last read it. If you track several files, keep one seen copy per file with the same name, or mirror the folder layout under `~/.seen`. Don't share one seen file across two plans. You'll get a diff of two different files. ### A seen copy with git If the folder is already in git, a commit is your seen copy. Commit after you read, then run `git diff HEAD -- ` next time to see only what changed since that commit, staged or not. That's the same idea with history built in. The guide on [how to diff Markdown files with git](how-to-diff-markdown-files-with-git.md) covers word diffs, comparing commits and cutting line-ending noise. For a wider look at the options, with and without git, see [how to see what changed in a Markdown file](see-what-changed-in-a-markdown-file.md). One caution. Commit the seen state on purpose, after you read, not on a timer. A snapshot taken before you read marks text as seen that you never saw. A good reader should remember what you last saw and open the file showing only the changes since then. That is part of what Sashmark is being built for; see the [roadmap](/roadmap). ## Ask your agent to write in a way you can follow Most of the churn that loses your place comes from how the agent edits. A full rewrite moves everything. An append moves nothing above it. You can ask for the second. Paste something like this into your prompt or project notes: > When you update a Markdown file I am reviewing, edit it in place. Do not rewrite the whole file. Add new notes, log lines and questions at the end of the section they belong to, not above existing text. Keep every existing heading exactly as written, in the same order. Do not rename, merge or reorder sections. Update the status and updated fields in the front matter each time you save, and set status to done only when you have finished writing. This does three useful things for you. Appends keep the text you've read where it was. Stable headings keep your bookmark valid. A status field that flips only at the end tells you when the file has settled. The agent won't follow it every time. When a diff against your seen copy shows the whole file changed, that's a sign it rewrote instead of editing. Ask it to keep to the rule and move on. ## A routine for a file the agent is still writing Sometimes you want to read a file while the agent is still working on it. A plan in progress, a running log, a handoff being drafted. Reading it the same way you read a finished file leads to reviewing half a thought. Use this routine instead: 1. **Check the status first.** Open the front matter. If it says something like `in-progress` or `drafting`, read for direction, not detail. Don't approve or act on anything yet. 2. **Wait for the done signal for real review.** When status says `done` or `ready-for-review`, the file has settled. That's when line-by-line reading pays off. 3. **Read top-down.** Start at the goal and the status, then work down. Agents often touch the header and the newest section. Reading in order means you see the frame before the detail. 4. **Note your heading when you stop.** Every time you look away, remember the heading you were under. 5. **Re-check the header after every reload.** Before you scroll back to your heading, look at the status and the updated date. If either changed, the file moved under you, and the part you'd already read may have changed too. 6. **Diff against your seen copy when it settles.** Once status is done, compare against the copy you saved last time. Read the changes, then save a new seen copy. If the file has no status field, add one. The guide to [writing Markdown docs your AI agent can follow](write-markdown-docs-your-ai-agent-can-follow.md) has a front matter block you can copy. ## Quick checklist Run through this when a file you care about is being rewritten: - [ ] I know the heading I was reading, not just the line number. - [ ] I checked the status and updated date after the last reload. - [ ] I have a seen copy or a commit from the last time I read this file. - [ ] I diffed against it instead of re-reading the whole file. - [ ] I saved a new seen copy after reading the changes. - [ ] My prompt asks the agent to append, edit in place and keep headings stable. - [ ] I waited for a done status before reviewing line by line. If you can tick most of these, a rewrite costs you a short diff instead of a full re-read. ## Where Sashmark fits Sashmark is a Markdown reader and editor for people whose AI agents write Markdown. It is in development and has not been released, and the app itself has no AI features. It is being built around the problem on this page: a file that keeps changing while you read it. See the [planned features](/features), the [help pages](/help) and the [roadmap](/roadmap) for where each part stands. Sashmark is in development. See what it is at [sashmark.com](https://www.sashmark.com/).