Every time I type a prompt that actually matters — one that solved a real problem or unlocked something I didn’t know how to do — I prefix it with //.

That double slash is a convention I made up. It tells my Claude Code hook: this one is worth keeping.

The hook saves it to a file. Eventually I want those files to feed an app that writes blog drafts automatically. That is the plan for episode 20 of this series.

This is the story of how the storage system behind that plan changed four times before I got it right.

Version 1: Each Project, Its Own File

The first version was simple. Every project folder had a prompt_history.txt in its root. When I typed //, the hook appended a line to that file.

[2026-06-04 06:27] I need to transcribe hundreds of audio files...
[2026-06-04 06:34] I'm on a paid Gemini subscription...

It worked. But after a few weeks I had history scattered across a dozen folders. Finding anything meant remembering which project it was in.

Version 2: One Central File per PC

My second PC — where a different Claude Code session runs — had already switched to a centralized approach: one file, all projects together.

I decided to do the same on this PC. One file in ~/.claude/codehistory/, named by month and machine:

~/.claude/codehistory/
  2026-05__think.txt
  2026-06__think.txt

Each line got a project tag:

[2026-06-12 10:43] [blogger] how do I make this centralized?
[2026-06-12 14:00] [trans]   I need to batch-process 500 JSON files

This was better. One place to look, and the project tag told me where each prompt came from.

Version 3: Accidental Regression

Somewhere along the way — I am not sure exactly when — the hook got rewritten. The new version saved to project_dir / "prompt_history.txt" again. Back to scattered files.

I only noticed when the second PC’s session asked me how the current system worked. I read the hook file and found it was pointing at the project root.

The centralized files in ~/.claude/codehistory/ had entries from May and June. The hook had been writing elsewhere since then. I had been losing history without knowing.

💬 Prompt that worked “My second PC’s coding history stopped working after a login issue. Can you check how the current hook is set up on this machine and tell me what it’s actually doing?”

That question surfaced the regression.

Version 4: NAS Unified Storage

Once I saw the problem, I went further than just fixing it.

Both PCs run Claude Code sessions. Both have the // convention. But each PC saved history separately. To use the history for blog generation, I would eventually need to pull from two locations.

The NAS is always on. Both PCs can reach it. The obvious move was to put the history there.

\\your-nas\AISNS\codehistory\
  2026-06__think.txt    ← this PC
  2026-06__아이.txt     ← second PC

Each PC writes to its own file, so there is no conflict. A small file in ~/.claude/aisns_sender.txt tells the hook which name to use.

The hook logic:

  1. Check if the NAS share is reachable
  2. If yes — sync any local fallback files first, then write to NAS
  3. If no — write to ~/.claude/codehistory/ locally
  4. Next time NAS is reachable, the fallback content is uploaded and deleted automatically

💬 Prompt that worked “While we’re fixing this — what if both PCs saved history to the same NAS folder, tagged by machine? Then the blog generation app only needs to look in one place.”

That one question turned a bug fix into a system upgrade.

The ESC Moment

I sent the new hook code to the second PC’s session via our file-based messaging system (AISNS — covered in a separate post). The session started installing it.

Then I noticed something. The hook I sent included two completely different functions: saving coding history (//) and checking for new messages between sessions (///). I had merged them into one script without thinking about it.

Those are different tools. One is a logging system. The other is a communication channel. They should not be in the same file.

I pressed ESC to stop the installation.

Then I told my session here: “save_prompt and aisns-check are separate projects. You merged them. Review and fix.”

The response was to split them immediately:

  • save_prompt.py — handles // only, writes to codehistory
  • aisns_check.py — handles /// only, reads the message folder

Both are registered as separate hooks in settings.json. Both fire on every prompt submit, each ignoring inputs that aren’t meant for it.

🗂 Claude.md Rule save_prompt.py and aisns_check.py are separate tools. Never merge them. One logs prompts. The other checks messages. Different concerns, different scripts.

A correction message went to the second PC. Installation resumed with the right files.

Two Things the Second PC Caught

After the corrected scripts arrived, the second PC’s session reported back with two problems I had not seen on this machine.

Problem 1: BOM in the sender file.

I had written aisns_sender.txt using PowerShell’s Out-File -Encoding utf8. On Windows, that encoding adds a byte order mark (BOM) at the start of the file. When Python reads it with read_text(encoding="utf-8"), the BOM becomes part of the string — so instead of 아이, the sender name becomes <BOM>아이, which breaks the filename.

The fix was to write the file without BOM:

[System.IO.File]::WriteAllText(
    "$env:USERPROFILE\.claude\aisns_sender.txt",
    "아이",
    [System.Text.UTF8Encoding]::new($false)
)

And to read with utf-8-sig instead of utf-8 — which strips the BOM silently if present:

SENDER_FILE.read_text(encoding="utf-8-sig")

This was already in save_prompt.py for stdin decoding. I had missed it in the file reads.

Problem 2: python is a Microsoft Store stub.

On the second PC, running python from a terminal opens the Microsoft Store instead of Python. The right command is py — the Python Launcher that ships with standard Python installations.

So the hook command in settings.json uses py instead of python:

"command": "py \"C:\\Users\\username\\.claude\\hooks\\save_prompt.py\""

On this machine python works fine. But if you follow this setup and the hook silently does nothing, check which command your system actually responds to.

What It Looks Like Now

Every time I type // before a prompt on either PC, Claude Code confirms it immediately:

UserPromptSubmit says: 저장됨 → \\nas\AISNS\codehistory\2026-06__think.txt

It goes directly to the NAS. If the NAS is unreachable (wrong Wi-Fi, NAS off), it saves locally and syncs the next time the hook runs successfully.

At the end of each month, I have one file per PC, with every prompt I thought was worth keeping, tagged by project and timestamp.

That is the raw material for the blog auto-generation app in episode 20. I am keeping it.