Claude Code Adds /cd — Carrying Your Warm Cache Across Repositories

Why preserving the prompt cache matters

The prompt cache pays off when you repeatedly send the same prefix. Cached input tokens are far cheaper than ordinary input, and the response comes back faster.

In a sweep, your shared context — coding conventions, preferred review lenses, prior exchanges — becomes that prefix. Restarting reset the prefix to zero every time. /cd keeps the prefix and swaps only cwd, so the cache benefit carries over.

Here is a rough estimate using my own numbers.

Shared prefix: ~12,000 tokens
Repositories to sweep: 4
 
Restart model: 12,000 tokens × 4 at full input price
/cd model:     12,000 once, then 3 reads at the cache-read price
 
If cache reads cost about 1/10 of input
  48,000  →  12,000 + (12,000 × 3 × 0.1) = ~15,600 token-equivalents
roughly a 70% reduction

The numbers shift with your assumptions, but the lever is clear. The larger your shared prefix and the more repos you cross, the more the preservation compounds. Latency drops for the same reason.

The destination CLAUDE.md arrives as a "message"

This is the behavior I watch most closely in operations.

After a /cd, the destination CLAUDE.md does not replace the system prompt; it arrives as a message appended to the conversation. The source conventions stay, and the destination's rules stack on top as instructions added later.

The upside is that context never breaks mid-sweep. You keep the direction you agreed on in the previous repo and layer the next repo's specifics on top.

The pitfall comes from the same structure. If the source and destination define conflicting rules, both linger in the conversation and compete. If the source says "write in plain form" and the destination says "write in polite form," the later instruction does not necessarily override the earlier one.

Given this, I switched to opening each repository's CLAUDE.md with a short "overrides for this repository" note — one line so that, even mid-sweep, I don't mistake which instruction reflects the current intent.

Session relocation and --resume / --continue

After a /cd, the session is relocated to the destination project's storage, and --resume and --continue resolve from there.

# Move the working directory during a session
/cd ../repo-b
 
# This session now belongs to repo-b's project history
# Later, to pick it back up in repo-b
claude --continue       # the session is visible from repo-b's side

There are two operational implications.

First, the sweep's history ends up tied to "the last project you were in." When you look back, you need to remember which project's history to open.

Second, a long session that hopped across repos collapses to a single re-entry point. In my case, I pick a fixed starting directory and /cd back to it before folding the session.

A real cross-repo procedure

Here is the flow I follow in daily sweeps, written so you can reproduce it.

1. Warm the shared prefix in the first directory

In the first repository, run through the context common to the whole sweep — review lenses, things to avoid. The prompt cache warms up at this point.

2. Move to the next repo with /cd

Without folding the session, move to the next directory with /cd. The shared prefix stays as the cache prefix, and the destination CLAUDE.md arrives as an appended message.

3. Confirm each repo's "overrides" up front

Read the destination-specific rules first and explicitly settle only the points that clash with the shared prefix. Skip this and the instruction collision gets hard to notice later.

4. Return to the start before folding

When everything is done, /cd back to the starting directory and then end the session. It keeps the re-entry door in one place.

Pushing teardown onto a post-session hook

The same June 18 update added post-session hooks that run after a session ends, which widens the room to push your "cleanup" onto Claude Code itself.

I used to delete .next and write an update log by hand after each repo. Moving teardown into a hook means I stop repeating the same chores on every pass.

A settings.json example:

{
  "hooks": {
    "PostSession": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": ".claude/teardown.sh"
          }
        ]
      }
    ]
  }
}

The script it calls sticks to cleanup.

#!/usr/bin/env bash
# .claude/teardown.sh — post-session cleanup
set -euo pipefail
 
# Clear build artifacts (avoid running out of space next time)
rm -rf ./.next 2>/dev/null || true
 
# Write a dated close log (fix TZ to avoid overwriting the prior day's log)
TS="$(TZ=Asia/Tokyo date '+%Y-%m-%d %H:%M')"
echo "[$TS] session closed in $(basename "$PWD")" >> ./.claude/session.log

The configuration safe mode that shipped alongside isolates a broken config and keeps starting up. In unattended runs, a settings mistake halting the whole session is the most painful failure, so a behavior that quarantines the problem and keeps going was a genuinely welcome improvement.

Things I watch when adopting it

A few cautions I keep in mind when folding /cd into operations.

First, coexisting conflicting rules. As noted, the destination CLAUDE.md arrives as an append, so the source policy remains. Write each repository's rules at a granularity that does not collide.

Second, awareness of relocation. A long sweep ties to the last project you were in, so without a fixed starting point you end up hunting for history.

Third, not over-preserving. Carrying context is an advantage, but dragging unrelated assumptions into a different domain adds noise to the reasoning. When the topic shifts hard, I sometimes choose a clean restart over preservation.

/cd is not a flashy feature. Still, for an indie developer hopping across repositories, it quietly trims the accumulating wait and cost. I hope it helps the operational design of anyone running similar cross-repo work. Thank you for reading.