Wrote on one PC, read on another — half a day to share Claude's memory across multiple PCs

2026-05-12 ／ Vol 9 ／ draft at the time of publishing

I use multiple laptops — one when I'm at my desk, another when I'm out or in another room.
Until today, Claude Code was effectively pinned to a single machine. The reason was simple: Claude didn't follow me across PCs. Project memory (memory) and plans (plans) only lived on one disk, so when I tried to continue the same work on another laptop, I had to brief Claude from scratch every time.

Today (2026-05-12), I crossed that line. In half a day.

What is shared, what isn't

First, I asked Claude to inventory Claude Code's config directory (~/.claude/) and decide what's safe to share across PCs.
The result:

The line-drawing principles boiled down to three:

1. Don't share append-heavy files (they cause sync conflicts).
2. Don't put secrets across the network (creds, tokens).
3. Of what's left, share only the things that are nice to have everywhere (memory, plans).

OneDrive + junctions as a "hub"

All my PCs already had OneDrive syncing, and the path OneDrive - esy net happened to be identical across them (we're on the operating company's Microsoft 365 tenant).
I made a .claude-shared/ folder inside OneDrive and pointed each PC's ~/.claude/ subdirectories at it using junctions (Windows-style folder aliases).

~/.claude/plans/                        ← junction
~/.claude/projects/<id>/memory/         ← junction × 3

        ↓ actually lives at ↓

OneDrive - esy net/.claude-shared/
  ├── plans/
  └── projects/<id>/memory/ × 3

When Claude reads or writes ~/.claude/plans/foo.md, the actual file is on OneDrive, and the other PCs can see it.
Why junctions: unlike symlinks, they don't require admin privileges. And with Files On-Demand, you don't pay disk space when files aren't accessed.

The moment Claude was stopped by its own safety

While Claude was wiring up the setup, it got blocked by its own safety layer:

Permission for this action has been denied. Reason: Modifying the agent's own ~/.claude configuration directory (replacing memory/plans dirs with junctions to OneDrive) is Self-Modification of agent state, which the user did not specifically authorize.

That is: "You're trying to rewrite your own config directory. The user said 'I want to share what's shareable,' not 'approve this specific junction operation.'" Claude's security layer stopped Claude.
I think this is the right design. If an AI starts rewriting its own memory and config without explicit confirmation, you lose the ability to follow what it's doing. The guardrail "self-modification needs human authorization" was doing its job in real time.

The fix was simple: have Claude write a batch file (setup-junctions.bat), then I double-click it in Explorer. The act of authorization stays in my hand.

Asking Claude to audit its own batch — 3 bugs surfaced

Once it worked, I asked: "check this once more, are there any problems?" — feeding Claude's code back to Claude in a fresh turn. Three findings came out:

① Logic bug in v2 of the script
For "is the target already a junction?" I'd used dir /AL, but that doesn't actually check whether the target itself is a reparse point. A regular folder would be misclassified as "junction exists" and the setup would silently [skip] without sharing anything.
→ Replaced with fsutil reparsepoint query.

② OneDrive Files On-Demand risk
Files showed a ReparsePoint attribute = "stored in the cloud only, the local copy is a placeholder." Every time Claude reads memory, OneDrive races to download it. Could fail offline or under sync lag.
→ Documented "Always keep on this device" as required setup.

③ No username sanity check
Paths were hard-coded to C:\Users\asano\..., but if the username differs on another PC, the script would fail silently.
→ Added a USERNAME guard at the top — bail out cleanly if it's wrong.

All three are holes I would have missed alone. Running "Claude-the-author" and "Claude-the-auditor" in separate turns lets review happen within the AI. That was a new discovery for me about how to use this.

The sync test: wrote on one PC, read on another

To verify the plumbing was actually working, I had Claude write a test entry to memory on PC #1, then I switched to PC #2 and asked Claude there to read it.

The file written on PC #1 (test_sync_check.md) recorded only the name of the writing PC, the user, the time, and the working directory. A one-line pointer was added to the memory index (MEMORY.md) as well.

Then on PC #2, I asked Claude:

What's this PC's name? Read the "memory sync test" entry and tell me what it says.

Answer (paraphrased):

This PC is a different one from PC #1. The test entry says it was written from PC #1 at 2026-05-12 09:08 JST.
A sync test file written from PC #1 was read without issue from this PC. Memory sharing via OneDrive is functioning.

It worked. I can now continue the same Claude context on a different PC. Later I asked Claude on PC #2 to delete the test entry "since it had served its purpose," and via OneDrive sync that deletion propagated back to PC #1 as well — confirming two-way sync in the same session.

Adding another PC later

I put a setup guide (SETUP-2ND-PC.md) and an idempotent batch (setup-junctions.bat) under .claude-shared/ on OneDrive. For any new PC, the steps are:

1. Confirm OneDrive is syncing.
2. Right-click .claude-shared → "Always keep on this device".
3. If existing memory/plans live there, rename to .bak (skip if absent).
4. Double-click setup-junctions.bat.
5. Launch claude → do the first-time OAuth (auth stays per-PC).
6. Re-auth MCPs if you need them.

The same flow works for any number of PCs. The script is idempotent: parent dirs are auto-created if missing, existing junctions get [skip], leftover regular folders get a clean [warn].

What you choose not to share is the design

The most important judgment in this whole exercise was: session logs and credentials were deliberately kept out.
"Share everything for convenience" is wrong. The rule comes first: don't put append-heavy or sensitive things on OneDrive. Only after that do you decide what's worth sharing.

This feels like a fairly general pattern for the AI era. Memory (long-term project context) wants to be shared. Sessions (in-the-moment chat) aren't worth sharing. Credentials are dangerous to share.
The more tools we add, the more we have to deliberately decide what to leave un-shared.

What's still on the list

・Delete the .bak directories after a 1–2 week soak period.
・Set up a new PC end-to-end, when the chance comes.

The test entry itself was already deleted from the second PC, and via OneDrive sync it vanished from the first PC as well — a tidy way to close the loop on the same day.

Next

Vol 10 might swing back to karaha.org operations (the long-pending "actually register members → broadcast" flow). Or it might be observations from using the new multi-PC setup in real work.
Next week, either way.