Okay so — it's Friday, the thing you built this week works, and you're about to close the laptop.
Somewhere in that closed laptop is a conversation four hundred messages long. The bit where you finally got your data to load.
The three failed attempts before it. The command that starts the thing. You're not worried about any of it, because it's all in the chat, and the chat is right there.
I want to tell you what happens Tuesday, and then I want you to spend ten minutes making it not happen.
The thing you lose isn't the code
Your code is fine. It's sitting in a folder with a name you chose, and nobody is deleting it.
What you lose is smaller and much worse. You lose how to start it.
The question that stops you on Tuesday is never "what does line 40 do." It's: do I open the terminal or the file?
Was it 'npm run dev' or the other one? Which of these three files is the real one?
And what on earth was I in the middle of?
None of those answers live in your code. Every one of them was in the chat.
The chat looked exactly like documentation
The internet's usual answer here is a lecture, and the lecture is useless to you.
The chat had headings. It had numbered steps. It answered your questions in order, it stayed open, and it scrolled back further than any notebook you've ever kept. Of course you treated it as the manual. It's the most manual-shaped thing on your screen.
But a manual is something you own. A chat is something you visit.
Weather, not the thing
Here's the sentence I'd tape to your monitor if you let me.
The conversation is weather. The folder is the thing.
Weather is real. It happened, you were there, it mattered. And you can't fetch last Tuesday's weather — you can only fetch a report somebody wrote down while it was happening. The folder is what's written down. Everything else is sky.
And there's a date on it
That's the metaphor. Here's the mechanism, and I read it rather than heard it.
If you use Claude Code, your conversations are files on your own disk: one '.jsonl' file per session, inside '~/.claude/projects/'.
That's good news right up until you read the retention rule. Run 'claude --version' first, because what follows is version-specific: on '@anthropic-ai/claude-code' 2.1.42, read on 25 July 2026, the default retention is 30 days.
The setting that controls it is called 'cleanupPeriodDays', and it lives in '~/.claude/settings.json' — that exact file, in your home folder, not one of the other two places settings can hide.
Before you go and change it, one warning, because I had this backwards in my first draft and our QC editor caught it.
Setting 'cleanupPeriodDays' to 0 does not mean keep forever. In 2.1.42 it means stop writing transcripts at all — the folder never even gets created.
We ran it — three throwaway home folders, identical runs, one setting different. 30 wrote a transcript.
1 wrote a transcript. 0 wrote nothing, twice.
Two more details. The sweep runs at startup — launching the tool is what triggers the delete pass.
And the clock is each file's own last-modified time, checked across every project folder, not just the one you're opening.
So the thing you poked at in June and got excited about again in August loses its transcript to the act of launching the tool, even if you launched it to work on something else entirely.
Nothing is being hidden from you. It's housekeeping, it's a documented setting, and 30 days of 32-megabyte JSON files is a sane default.
But "the chat is my changelog" and "the changelog deletes itself in a month, at a moment I trigger by hand" can't both be true, and only one of them is.
I checked that tool first-hand. I won't tell you what the browser chat products keep, or for how long, because I haven't read their code and neither has anyone who told me.
The point survives either way: none of it is in your folder.
Go and look at yours
Ten seconds. Save this as 'age.cjs' — next to your code, and yes, that extension matters. Lots of starter projects put '"type": "module"' in their 'package.json', and in one of those folders a file ending '.js' can't use 'require' at all; it dies on line 1. Ending it '.cjs' opts this one file out of that. Open a terminal in your project folder — not your home folder — and run 'node age.cjs'.
const fs = require('fs'); const os = require('os'); const path = require('path'); // Claude Code keeps one .jsonl transcript per session in here. const root = path.join(os.homedir(), '.claude', 'projects'); if (!fs.existsSync(root)) { console.log('No transcript folder here - nothing to look at.'); process.exit(0); } for (const project of fs.readdirSync(root)) { const dir = path.join(root, project); if (!fs.statSync(dir).isDirectory()) continue; for (const file of fs.readdirSync(dir)) { if (!file.endsWith('.jsonl')) continue; const stat = fs.statSync(path.join(dir, file)); // The countdown runs on last-modified time, not on when you started. const ageDays = (Date.now() - stat.mtimeMs) / 86400000; const mb = (stat.size / 1048576).toFixed(1); // The 30 assumes the default. If you've set cleanupPeriodDays yourself, // change it here too or this countdown is fiction. console.log(Math.floor(30 - ageDays) + ' days left | ' + mb + ' MB | ' + project); } }
You get one line per session transcript — so a project you've come back to four times prints four lines, not one. Mine, the session I cared about:
29 days left | 32.1 MB | -home-user
Thirty-two megabytes. 2,189 lines of JSON. One week.
Now's the time to act: set 'cleanupPeriodDays' to 365 in '~/.claude/settings.json' and leave 0 alone. On this machine that file doesn't exist yet — a cheaper problem than a wrong value in it.
And here's the part that got me: even if that file lived forever, it wouldn't help Tuesday-me.
It's a recording, not a document, and nobody re-reads a recording to find out how to start a program.
So the folder isn't missing a backup — it's missing a page nobody ever wrote.
The ten lines
Okay so — this is the whole build, and it's the smallest thing I've ever asked a reader to make.
Open a text editor. New file, called 'NOTES.txt'. Save it in the folder with your code — same folder as the files, not Documents, not Desktop. Then write five headings and answer them in your own words. Here's mine, from a thing I half-built last month:
WHAT THIS IS A page that reads my bank export and prints one monthly total. Just a page. No server, no accounts. HOW I START IT Double-click index.html. It opens in Chrome. That's it. WHICH FILE DOES WHAT index.html - the page, the file picker, the button parse.js - turns the CSV text into rows. All the real work is here. style.css - colours only. Safe to ignore. WHERE I STOPPED parse.js breaks on amounts with a comma inside them, like "1,240.00" - it reads that as two columns and the total comes out wrong. NEXT THING I WAS GOING TO TRY Split on commas that are NOT inside quote marks. No idea how yet.
Four rules, and they're what keep it from being a chore.
Hand-write it. Don't ask the AI for it. If a tool generates that file you've made one more thing you don't understand, and the whole value is that it came out of your own head.
"NEXT THING I WAS GOING TO TRY" is the most valuable line in the file. It's also the one you'll want to skip, because writing it feels like admitting you're stuck.
Write it anyway. That sentence is why Tuesday takes four minutes instead of forty.
If you can't write a line, write the question instead. "WHICH FILE DOES WHAT — no idea what utils.js is for, never opened it." That's a real, useful line, and it tells Tuesday-you exactly where to look.
Ten lines is the target, not the minimum. If it grows to two pages you'll stop keeping it current by Wednesday, and a stale note is worse than none.
Why this matters
Nothing in that file needs git. No install, no account, no commit, no command to remember. It's a text file in a folder, on a laptop you've never backed up.
I'm saying that plainly because "keep a note next to your code" gets heard as a version-control sermon, and they're not the same thing.
Version control is a real skill, worth having later, when you want it. This is a text file. You already know how to make one.
What it buys you is momentum, which is the only thing that really decides whether a beginner project gets finished.
Projects don't die because the code was bad. They die on the Tuesday when picking it up again costs forty minutes of archaeology and there are twenty minutes free — so you don't, and next week you don't, and a month later "the CSV thing" is something you used to be building.
Then paste it back
Here's the half people miss. That file isn't only insurance — it's your opening move. Next time you sit down with an assistant on this project, paste those ten lines in first, before the question, before anything else.
You've just handed it the thing it cannot know: what this is, which file matters, and where you stopped.
Which is also how you find out whether your note is any good. Open a brand-new session, paste the ten lines, and ask one question:
Given only this, what file do I open, and what was I in the middle of?
If it comes back right, your note works and you get to feel smug. If it comes back vague, you haven't failed a test — you've located the vague line in fifteen seconds, and you can fix it while you still remember the answer.
I ran that check on a note I'd written lazily, and it came back confidently wrong about which file to open. I rewrote two lines.
Final thought
I'm handing you this on a Friday because Friday is when the gap opens. You close the laptop feeling good, and the version of you who remembers everything doesn't come back on Tuesday.
So don't close it yet. Open a text editor, make 'NOTES.txt' in the folder with your code, and write the "WHERE I STOPPED" line — just that one, whatever mess you're actually in the middle of.
The other four headings can wait until you've had coffee.
That one sentence is the whole article. Everything else is just making it comfortable to write.