--- title: You and your agent editing the same Markdown file slug: edit-the-same-markdown-file-as-your-ai-agent excerpt: When you and an AI agent both write to one Markdown file, whoever saves last can wipe out the other's work. Here is a git routine you can use today. quickAnswer: Save your edits and commit the file before you start the agent. Give the agent one section or one job, and don't type in the file while it writes. When it finishes, read its changes with git diff, and use git restore only if you want to throw its changes away. A good Markdown editor should also reload in place, show what changed, give you a clear choice when the file changes under unsaved edits, and write only when you save. keyTakeaways: - Two writers and one file means whoever saves last can overwrite the other, and nothing warns you. - Commit a checkpoint before every agent run so you always have a version to compare with and go back to. - Give the agent one section or one job, and keep your hands off the file while it writes. - Check the agent's changes with git diff. git restore puts the file back, but it throws away the working copy changes. - A good editor should reload in place, show what changed since you last looked, let you keep your edits or load the agent's version, and write only when you save. publishedDate: 2026-10-19 dateModified: 2026-10-19 author: Bobby Huang cluster: A role: post status: published faq: - q: Why did my edit disappear after the agent finished? a: Most likely the agent read the file before you made your change, then wrote its whole version back. Its save replaced the file on disk, and your change was never in its copy. A commit before the run and a git diff after it help you see what changed. - q: Is it safe to type in the file while the agent is writing to it? a: It is the riskiest moment. Two programs are working from different copies of the file, and the last save wins. Wait until the agent is done, check its changes, then carry on. - q: What does git restore do to my file? a: It puts the file back to a saved version. Any changes in your working copy that you haven't committed or staged are thrown away, so read git diff first and only restore when you're sure you don't want those changes. related: - keep-your-place-while-your-agent-rewrites-the-file - see-what-changed-in-a-markdown-file - how-to-diff-markdown-files-with-git --- You keep a plan in Markdown. Your AI agent works from it, updates it, and ticks things off. You also edit it, because it's your plan. Most days that's fine. Then one afternoon you fix a step, the agent saves a few seconds later, and your fix is gone. Nobody got an error. The file just looks like the agent's version. That's the core problem with two writers on the same Markdown file. Neither side knows what the other changed since it last read the file, so the last save wins. ## Why two writers on one file go wrong Say you have `plan.md` open. You read it, rewrite step 4, and leave the change unsaved while you think. Meanwhile you ask your agent to add a testing section. The agent reads `plan.md` from disk, which still has the old step 4, adds its section, and writes the whole file back. Now there are two versions. The one on disk has the agent's new section and the old step 4. The one on your screen has your new step 4 and no testing section. If you save, you write over the agent's section. If you reload, you lose your step 4. If your editor reloads on its own, you may not even notice your change went away. The reverse happens too. You save your step 4, then the agent, still working from the copy it read earlier, saves its version and writes the old step 4 back over yours. No one did anything wrong. Each program saved what it had. The trouble is that each one had a different copy. ## A safe routine for sharing one file with your agent This routine works with any editor and any agent. It needs git in the folder and adds a few quick steps per run. 1. **Save your edits before you start the agent.** Whatever is unsaved on your screen is the easiest thing to lose. Get it onto disk first. 2. **Commit a checkpoint.** Stage the file and commit it, so you have a snapshot to compare with and go back to: ```sh git add plan.md git commit -m "Checkpoint before agent run" ``` 3. **Give the agent one section or one job.** "Add a testing section under step 6" is easier to check than "improve the plan". Small changes on each side mean less to untangle. 4. **Don't type in the file while the agent is writing it.** Read it, think, make notes somewhere else. Wait until the agent says it's done. 5. **Check what the agent changed.** With nothing staged since your commit, plain `git diff` shows everything that changed in the file since the checkpoint: ```sh git diff plan.md ``` The guide on [how to diff Markdown files with git](how-to-diff-markdown-files-with-git.md) covers reading that output, and [seeing what changed in a Markdown file](see-what-changed-in-a-markdown-file.md) covers other ways to spot changes. 6. **Go back if you need to.** If the agent's change is wrong, `git restore` puts the file back to your last commit (or staged version): ```sh git restore plan.md ``` Be careful here. `git restore` throws away the changes in your working copy of the file. Anything you or the agent changed since the last commit or stage is gone. Read the diff first, and only restore when you're sure. 7. **Commit again, then carry on.** If the change is good, commit it. That's your next checkpoint, and your next round of edits starts from a clean point. That's the whole routine: save, commit, one job, hands off, diff, then keep or restore. It doesn't stop both sides from writing to the file, but it gives you a checkpoint to compare with and a way back. ## What a good editor should do when the file changes under you The routine above relies on your discipline. Some days you'll have unsaved edits open when the agent writes the file anyway. That's when the editor matters. ### Reload in place and keep your place When you have no unsaved edits and the agent writes the file, a good editor should show the new version right where you are. It shouldn't jump you to the top. Keeping your place is its own topic, covered in [keep your place while your agent rewrites the file](keep-your-place-while-your-agent-rewrites-the-file.md). Sashmark is being built to reload in place and keep your spot; the [roadmap](/roadmap) shows where it stands. ### Show what changed since you last looked A good editor should highlight what the agent changed since you last read the file, so you don't need to run git just to check. Sashmark is planned to highlight what changed since you last looked, with no git needed. ### Unsaved edits: a clear choice, and nothing written until you choose If you have unsaved edits and the agent writes the file, a good editor should tell you the file changed on disk and keep your edits on screen. Then it should give you two plain choices: keep your edits, or load the agent's version. Loading the agent's version drops your unsaved edits, so it should be your choice, never the editor's. Nothing should be written to disk until you save. Sashmark is planned to offer that choice, keep mine or load theirs, and to write only when you save; the [roadmap](/roadmap) shows how far along it is. ### Save only what you changed When you save, a good editor should write only the lines you edited and leave every other line, including its line ending, byte for byte as it was. That keeps the agent's next diff small. [What a byte-for-byte round-trip save is](what-is-a-byte-for-byte-round-trip-save.md) explains the idea, and [why editors reformat Markdown on save](why-editors-reformat-markdown-on-save.md) explains what goes wrong without it. Sashmark is being built to leave lines you did not edit byte for byte the same. ## A short checklist for the next agent run - [ ] I saved my edits before starting the agent. - [ ] I committed a checkpoint of `plan.md`. - [ ] I gave the agent one section or one job. - [ ] I kept out of the file while the agent wrote it. - [ ] I read the agent's changes with `git diff` before going on. - [ ] I only used `git restore` when I was sure I didn't want those changes. ## Where Sashmark fits Sashmark is a Markdown reader and editor for people whose AI agents write Markdown, being built for Mac, Windows and Linux. It is in development and has not been released, and the app itself has no AI features. It is planned to reload a file in place and keep your spot, show what changed since you last looked, give you a clear keep mine or load theirs choice when the file changes under unsaved edits, and write only when you save, leaving lines you did not edit byte for byte the same. When Sashmark is released, installers will come only from the Sashmark website. 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/).