Reinstalling your Claude Code environment on a new machine

A developer detailed how to rebuild a complete Claude Code environment on a new machine by leveraging files stored in the `~/.claude/` directory. The global `CLAUDE.md`, reference guides, custom commands, and statusline configurations all live in files that can be restored with a single prompt, provided the prompt was prepared in advance. The developer also shared a custom statusline script that displays real-time token consumption and context usage, which is available on GitHub.

New machine. Install Claude Code. And then: Claude knows nothing. The development rules encoded in the global CLAUDE.md, the reference guides, the statusline displaying token consumption in real time, the plugins — all of it stayed on the old machine. The bad news: none of this syncs automatically. The good news: everything lives in files. A single prompt can rebuild the complete environment in minutes — provided you prepared that prompt in advance. The Claude Code global environment is concentrated in one folder: ~/.claude/ . What you'll find there: CLAUDE.md — global instructions: how to work, which rules apply across all projects settings.json — technical configuration: permissions, statusline, hooks hooks/ — scripts executed on Claude Code events commands/ — custom slash commands /audit-memory , etc. memory/ — global memories projects/<cwd /memory/ — per-project memoriesThis folder is neither versioned nor synced by default. Change machines, and the folder disappears. Everything you built over sessions goes with it. Reference files you store there — development guides, language-specific best practices — aren't auto-loaded. Claude reads them only when explicitly asked. They don't survive a machine change without manual intervention either. ~/.claude/CLAUDE.md is loaded in every session, across all projects. This is where you encode what must apply everywhere: how Claude should work, which restrictions are active, how commits should be written, how automatic memory works. It's also the hardest file to reconstruct from memory — because every rule it contains came from a concrete experience. A commit convention encoded after discovering what you didn't want in messages. A restriction on .env files added after an incident. A context economy principle that took weeks to calibrate. The structure that works well in practice: Target: under 100 lines. Beyond that, the file starts loading irrelevant context for most tasks. Rarely-useful sections Go best practices, detailed development guide go into separate files referenced as plain text. Some knowledge is too voluminous for the main CLAUDE.md but too specific for a project CLAUDE.md. The solution: reference files in ~/.claude/ , read on demand. Concrete examples: DEVELOPPEMENT-PROPRE.md — core principles: YAGNI, robustness/testability/simplicity triangle, code review checklist, anti-patterns to avoid go-best-practices.md — Go-specific patterns with code examples: error handling, concurrency, PostgreSQL, table-driven testing, structured loggingThe global CLAUDE.md only contains a reference line: Development Guide: ~/.claude/DEVELOPPEMENT-PROPRE.md Go Best Practices patterns, code examples : ~/.claude/go-best-practices.md Claude reads these files when relevant to the task. The rest of the time, they take no context space. Claude Code supports a configurable statusline in ~/.claude/settings.json . A second file, settings.local.json not versioned , handles tool permissions — what can run without confirmation, what's blocked. Keeping them separate avoids exposing your permissions in a shared repo. { "statusLine": { "type": "command", "command": "bash /home/YOUR USER/.claude/hooks/statusline.sh" } } The script displays in the Claude Code bar information that isn't available natively: context consumption as a percentage, remaining token estimate, current git branch. 🌿 main │ 🤖 Sonnet 4.6 │ 🟢 Ctx: ▓▓░░░░░░ 34% │ ⏱ 46% → 19h00 3h20m │ 📅 ~59% Mon 14h The script scrapes the /usage endpoint in background via tmux, caching results for 5 minutes in ~/.claude/usage-exact.json . Requirements: bash 4+ , jq , tmux , python3 . The full script is available on GitHub https://github.com/ohugonnot/coder-proprement . Without this script, the only consumption indicator is the progress bar in the interface — no percentage, no estimate. Claude Code supports a plugin skills system that enriches sessions with specialized workflows. They install via: claude plugins install <plugin-name Plugins that genuinely change how you work: They reinstall with a single command. The only prerequisite is having the list of plugins you were using — hence the value of noting it down before switching machines. Project memories ~/.claude/projects/<cwd /memory/ don't always need to be manually migrated. They age quickly — project type memories especially. Reopening a project in a fresh environment is an opportunity to let them rebuild naturally, session by session, with up-to-date information. What's worth migrating first: global memories ~/.claude/memory/ . These are cross-project preferences — the user profile technical level, knowledge domains , feedback that applies to all projects expected response style, communication rules . This information takes time to rebuild because it comes from experience accumulated across multiple projects. For feedback memories especially: each rule encodes a past correction. "Don't summarize what we just did at the end of the message" — Claude needs to be corrected several times before it makes it into a memory. On a new environment without that memory, you start those corrections from scratch. The real solution to this problem isn't syncing files — it's having a bootstrap prompt that recreates everything from scratch. A document containing: ~/.claude/CLAUDE.md settings.json configurationGive this document to Claude on the new environment with the instruction "recreate all of this." Claude creates the files, configures the settings, installs what it can install. In 10 minutes, the environment is functional. The associated CLAUDE.md context below is that document — it contains the exact content of all three ~/.claude/ files, the memories to restore, and the verification checklist. The advantage over file sync: it's an opportunity to review and update. A bootstrap prompt maintained over time reflects the actual current state of what you want — not a frozen snapshot of the old machine. The associated CLAUDE.md context at the bottom of this page contains a complete concrete example: the global CLAUDE.md, settings.json configuration, plugin list, and a post-installation verification checklist. Everything Claude knows about how you want to work lives in files. Those files don't sync, don't back up, and don't survive a machine change without conscious intervention. The discipline required: treat ~/.claude/ like dotfiles — something you version, maintain, and know how to restore completely from scratch. The associated CLAUDE.md context below contains the complete bootstrap prompt. 📄 Associated CLAUDE.md