Support named memory profiles (e.g., work vs. personal contexts)

Resolved 💬 3 comments Opened Mar 29, 2026 by daltlc Closed May 2, 2026

Problem

Claude Code's auto-memory is scoped per project directory, which works great for keeping individual repos separate. However, there's no way to share behavioral context across multiple related projects.

Freelancers and consultants juggle multiple clients, each with different conventions, tooling, tone, and domain knowledge. Today, they'd need to duplicate CLAUDE.md instructions across every client repo — and memory learned in one client repo (like "this client prefers X") doesn't carry over to their other repos.

Developers with distinct contexts — work vs. personal, or different teams within an org — want Claude to behave differently depending on context. A work context might mean formal tone, specific CI workflows, and corporate tooling preferences. A personal context might mean experimental, terse, different language preferences. Currently there's no way to group repos under a shared behavioral umbrella.

The existing hierarchy doesn't solve this. User-level ~/.claude/CLAUDE.md applies to everything — you can't have work preferences that only apply to work repos. Project-level CLAUDE.md is per-repo — you can't share learned context across related repos without manual duplication. There's a missing middle layer: a grouping mechanism between "all projects" and "one project."

Proposed Solution

Named memory profiles that can be activated per session or per project:

  • ~/.claude/profiles/work/memory/ and ~/.claude/profiles/personal/memory/
  • A way to assign a profile to a project (e.g., in .claude/settings.local.json: "profile": "work")
  • A command to switch profiles mid-session (e.g., /profile work)
  • Profile-level CLAUDE.md that layers between user-level and project-level

Alternatives Considered

  • Separate CLAUDE.md per repo — works for project-specific instructions but doesn't share context across repos in the same "group"
  • Custom skills to swap memory files — fragile, can't redirect where Claude Code reads auto-memory from
  • User-level ~/.claude/CLAUDE.md — too broad, applies to everything with no way to scope

Use Cases

  • Freelancer managing Client A vs. Client B with different conventions and domain knowledge
  • Work vs. personal coding styles, tone, and tooling preferences
  • Multiple teams within an org with different standards (frontend team vs. infra team)
  • Open source contributor who wants different behavior for their own projects vs. upstream repos

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗