Claude Code Local: Skills, Memory, and Persistence

Hey there! How`s everything going? This is Lena.

A few weeks ago I was sitting in my usual coffee spot, trying to get Claude Code to remember something I'd explained the week before. It didn't. I had to retype the whole context again, and I remember just staring at the screen thinking — wait, where did everything go?

That moment sent me down a rabbit hole I didn't expect. Because "local" in Claude Code doesn't mean what I assumed it meant. And the gap between what I thought I understood and what's actually happening is… indeed worth writing down.

What Running Claude Code Locally Actually Means

Local CLI execution vs cloud-hosted sessions

When you run Claude Code locally, the CLI lives on your machine — but the actual model inference still happens in Anthropic's cloud. Your terminal talks to the API; the heavy lifting isn't happening on your laptop.

What is local: your file system, your project structure, your command history, the output files Claude creates. What isn't local: the model weights, the compute, and anything Claude "knows" between sessions.

This distinction matters a lot if you're building agent workflows and expecting some kind of persistent intelligence to accumulate locally. It won't — not automatically, anyway.

Installing Claude Code on Linux, Mac, Windows

As of March 2026, Claude Code is available via npm and requires Node.js 18+. Installation is the same across platforms:

npm install -g @anthropic-ai/claude-code

Then authenticate:

claude login

On Linux, you may need to add the npm global bin directory to your PATH if the claude command isn't found after install. Windows users running WSL2 should treat the environment as Linux. Native Windows PowerShell support exists but has some edge cases with file path handling — worth checking Anthropic's Claude Code documentation before assuming your setup is standard.

Local Skills and Memory

CLAUDE.md and project-level skill files

This is the part I had to re-read twice.

Claude Code reads a file called CLAUDE.md from your project root at the start of each session. Think of it as a briefing document — you write instructions there, and Claude picks them up every time you open the project.

# My Project Context

- This is a Next.js 14 app using TypeScript
- Always use pnpm, not npm
- Component files live in /src/components
- Prefer functional components with explicit return types

That's not memory. That's context injection. The distinction is subtle but it changes how you think about the tool. Claude isn't remembering — it's ​reading​. Every session.

You can also place CLAUDE.md files in subdirectories. Claude Code will load the relevant one based on where you're working in the project. This is useful if different parts of your codebase have different conventions.

How local context accumulates across sessions

Here's what I noticed when I started paying attention: context doesn't accumulate on its own. What can accumulate is the CLAUDE.md file itself — if you update it after each session with things you learned or patterns that worked.

It's manual. You are the memory layer.

Some people build small scripts to auto-append session summaries to CLAUDE.md. That's a reasonable workaround. But out of the box, the file is static until you edit it.

What 'memory' means in Claude Code today

As of early 2026, Claude Code doesn't have native persistent memory the way some newer agent frameworks do. There's no background process quietly building a knowledge graph of your preferences.

What exists is this:

• CLAUDE.md for project-level context
• Your conversation history within a single session
• Files Claude creates or modifies — which persist because they're just files

That last one is actually more powerful than it sounds. If Claude generates a reusable utility function and saves it to your repo, that capability is now in version control. It's persistent in the most reliable way possible.

Does Local Execution Make Capability Persistence Easier?

Advantages — persistent files, version control, local skill libraries

Running locally gives you real advantages for building persistent capability — just not in the way I first imagined.

Version control is the killer feature here. Every pattern Claude helps you build becomes a commit. Your git history becomes a timeline of accumulated capability. That's real persistence — just not automated.

Limits — still single-agent, still no cross-agent inheritance

Claude Code runs as a single agent in a single session. There's no built-in mechanism for one Claude Code session to share what it learned with another session on a different project — or even a different terminal window on the same project.

This is the hard limit. You can't have Claude Code on Project A automatically inform Claude Code on Project B. The learning doesn't propagate. Each session starts from whatever you've manually put into CLAUDE.md and whatever files exist in the project.

For teams, this creates an interesting challenge. If one developer has refined a great CLAUDE.md for your shared codebase, others need to use that same file. The collaboration is human-mediated, not agent-mediated. Projects like LangGraph's multi-agent coordination patterns explore what cross-agent coordination could look like, but Claude Code doesn't implement that natively yet.

The gap between local state and network-level reusable assets

I kept thinking about this gap. Local state is yours — it lives in your file system, your git repo, your CLAUDE.md. That's all great. But it doesn't participate in anything larger.

Network-level reusable assets would mean: something Claude learns while helping you could, in some validated form, become available to other agents working on similar problems. Local Claude Code sits on one side of that gap. Whether and how that gap closes is something I'm still watching.

Local Agent as a Starting Point for Capability Engineering

Building reusable patterns locally before publishing to a network

One framing that helped me: local Claude Code is a good place to develop patterns before they're ready to share anywhere.

You iterate, you refine, you encode the working version into files and CLAUDE.md. When a pattern is solid — a prompt template, a code generation workflow, a debugging approach — it's documented and testable. That's the raw material for any future capability-sharing system.

The OpenAI Swarm project experimented with lightweight multi-agent coordination, and one takeaway was that well-defined individual agent behaviors are the prerequisite for effective collaboration. Local-first isn't a limitation — it's where the work gets done before it scales.

Why local-first doesn't mean local-only

I think the mistake I made early on was treating "local" as a permanent state rather than a starting point.

Local execution gives you control, speed, and integration with your actual file system. It's where you do the careful work of figuring out what a good workflow actually looks like. Once that's figured out, the question of how to share it — with teammates, with other projects, with other agents — becomes a separate and interesting problem.

The A2A (Agent-to-Agent) protocol specification published by Google is one attempt to formalize how agents communicate capabilities across systems. Whether Claude Code integrates with these emerging standards is worth following.

Limits and Tradeoffs

A few things I'd want someone to know before they start:

CLAUDE.md​ has a context limit. If it gets too long, it starts pushing other useful context out of the window. Keep it focused. Prune regularly.

Local files are only as good as your git hygiene. If you're not committing Claude's outputs consistently, the "persistence" disappears when you switch machines or reset your environment.

The API still has rate limits. Running locally doesn't exempt you from usage constraints. Heavy agentic sessions — especially with file operations and tool use — can hit limits faster than conversational use. Anthropic's rate limit documentation has the current tier details.

Claude Code's tool​ use​​ is sandboxed per session. File reads, writes, and terminal commands work within the session. Nothing carries over unless it lands in a file.

I'm still not totally sure I understand all the edges here. But this is my current picture of it.

FAQ

1. How do I install Claude Code locally?

Install via npm: npm install -g @anthropic-ai/claude-code, then run claude login to authenticate. Node.js 18 or higher is required. On Linux/WSL, verify your PATH includes the npm global bin directory.

2. Does Claude Code have persistent memory?

Not in the automatic sense. Each session starts fresh. Persistence comes from CLAUDE.md (which you maintain manually) and from files Claude creates in your project that get committed to version control.

3. What is CLAUDE.md and how does it work?

It's a plain markdown file placed in your project root (and optionally in subdirectories). Claude Code reads it at the start of every session. You use it to document project context, conventions, and preferences. Think of it as a briefing document, not a memory system.

4. Can Claude Code skills transfer between projects?

Not automatically. You can manually copy or adapt your CLAUDE.md and any reusable files from one project to another, but there's no built-in cross-project capability sharing. This is one of the meaningful limits of the current local-first architecture.

5. Is local Claude Code better than cloud-hosted for agent workflows?

It depends on what you're optimizing for. Local gives you direct file system access, faster iteration on project-specific context, and full control over your files. Cloud-hosted (like Claude.ai Projects) gives you easier sharing and collaboration. For solo development workflows with complex local codebases, local tends to win. For team workflows or non-technical users, cloud features may matter more.

Previous Posts:

Previous Posts:

• If you want to better understand how Claude Code handles skills and context under the hood:Claude Code Skills Feature Explained
• If you're exploring how to build, reuse, and extend skills across projects:Claude Code Skills: Build, Share, Extend Guide
• If you're trying to clarify the difference between skill files and actual agent capability:Claude Skills: skill.md vs Agent Capability
• If you're thinking about chaining behaviors and building more structured agent workflows:Agent Hooks: AI Execution Chains Explained
• If you're looking into MCP as a way to extend Claude Code beyond local limitations:How MCP Servers Work