claude-code - 💡(How to fix) Fix [FEATURE] Auto Memory Scoping Limitation [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#54547Fetched 2026-04-30 06:42:38
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Timeline (top)
labeled ×3closed ×1commented ×1
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing requests and this feature hasn't been requested yet
  • This is a single feature request (not multiple features)

Problem Statement

Currently, Claude Code's auto memory writes only to ~/.claude/CLAUDE.md (user-level), meaning memories accumulate globally across all projects rather than being scoped to the project where they were learned. A project-level auto memory option would be more useful for keeping context relevant and potentially shareable across teams.

Proposed Solution

Introduce an autoMemoryScope setting that lets users control where auto memory is written. By default it keeps the current global behavior (~/.claude/CLAUDE.md), but when set to project, Claude writes memories to .claude/memory/ inside the project directory instead. A both option could also be supported for users who want memories captured at both levels. This gives teams the flexibility to keep project-specific context isolated, optionally commit it to version control for shared team knowledge, and prevent unrelated project memories from bleeding into each other. CI environments could also benefit by scoping memory to the project rather than relying on a developer's global home folder.

Alternative Solutions

No response

Priority

Medium - Would be very helpful

Feature Category

Other

Use Case Example

No response

Additional Context

No response

extent analysis

TL;DR

Introduce an autoMemoryScope setting to control where auto memory is written, allowing users to choose between global, project-level, or both.

Guidance

  • Consider adding a configuration option to the existing settings to accommodate the autoMemoryScope feature.
  • Evaluate the trade-offs between storing memories at the global level versus the project level, and decide on a default behavior.
  • Think about how to handle memories written to the project level, such as whether they should be committed to version control.
  • Investigate how to ensure backward compatibility with existing memories written to the global location.

Example

No code example is provided as the issue does not contain sufficient technical details.

Notes

The proposed solution requires careful consideration of the implications of storing memories at different scopes, including potential performance and data management issues.

Recommendation

Apply workaround: Introduce the autoMemoryScope setting to provide users with flexibility in managing their memories, as this feature is not currently available and would require significant changes to the existing codebase.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [FEATURE] Auto Memory Scoping Limitation [1 comments, 2 participants]