Feature Request: Scoped Context in during
Feature Request: Directory-Scoped Memory Loading Mode
Problem Description
Currently, Claude Code always loads CLAUDE.md files hierarchically - from the current working directory up to the repository root. There's no way to scope Claude's context to just the current directory, which creates several workflow issues:
Current Behavior (Always Hierarchical):
When running claude from /project/backend/src/:
- ✅ Loads
/project/backend/src/CLAUDE.md - ✅ Loads
/project/backend/CLAUDE.md - ✅ Loads
/project/CLAUDE.md - ✅ Loads
~/.claude/CLAUDE.md
The Problem:
- Context Pollution: Working on backend code but getting frontend context from
/project/CLAUDE.md - Conflicting Instructions: Different parts of a monorepo may have conflicting coding standards
- Cognitive Overhead: Too much irrelevant context when focusing on a specific subsystem
- No Isolation: Can't work in a "clean" directory context without parent influences
Proposed Solution
Add a directory-scoped mode that allows Claude to load only the current directory's context:
Option 1: CLI Flag
claude --scope-local # Only load current directory + user global
claude --scope-directory # Alternative naming
Option 2: CLAUDE.md Directive
<!-- CLAUDE_SCOPE: LOCAL -->
# This directory should be treated as isolated context
Option 3: Settings Configuration
{
"memoryScope": "local", // "hierarchical" (default) | "local" | "user-only"
"directories": {
"/backend/": { "scope": "local" },
"/frontend/": { "scope": "hierarchical" }
}
}
Use Cases
1. Monorepo with Different Tech Stacks
/project/
├── CLAUDE.md # "Use TypeScript for everything"
├── /backend/
│ └── CLAUDE.md # "Use Python, follow PEP 8"
└── /frontend/
└── CLAUDE.md # "Use React, follow Airbnb style"
Working in /backend/ shouldn't inherit TypeScript instructions.
2. Legacy Code Isolation
/project/
├── CLAUDE.md # Modern practices
└── /legacy/
└── CLAUDE.md # "This is legacy code, minimal changes only"
When refactoring legacy code, don't want modern architectural guidance.
3. Specialized Tools/Libraries
/project/
├── /app/
└── /tools/
└── CLAUDE.md # "This directory uses custom build system"
Tool directories have unique contexts that shouldn't inherit app conventions.
4. Team Workflow Isolation
/project/
├── CLAUDE.md # Team-wide standards
└── /experiments/
└── CLAUDE.md # "Ignore all parent conventions, experimental space"
Expected Behavior
Local Scope Mode:
When running claude --scope-local from /project/backend/src/:
- ✅ Loads
/project/backend/src/CLAUDE.md(current directory) - ✅ Loads
~/.claude/CLAUDE.md(user global - always included) - ❌ Skips
/project/backend/CLAUDE.md(parent) - ❌ Skips
/project/CLAUDE.md(ancestor)
Hierarchical Mode (Default):
- Current behavior unchanged for backward compatibility
Benefits
- Cleaner Context: Focus on relevant instructions only
- Conflict Resolution: Eliminate contradictory guidance between layers
- Performance: Faster loading with less context to process
- Mental Model: Matches developer expectation of "working in this directory"
- Flexibility: Choose hierarchical vs. scoped based on task
Implementation Suggestions
- Preserve Current Default: Hierarchical loading remains default behavior
- Clear Indication: Show which CLAUDE.md files were loaded via
/memorycommand - Override Mechanism: Allow CLI flags to override configured settings
- Documentation: Clear guidance on when to use each mode
Alternative Considered
- Manual Memory Management: Using
/memorycommand to selectively load files - Rejected: Too manual, breaks workflow
- Import-Only Mode: Rely entirely on
@importsin CLAUDE.md - Rejected: Still requires hierarchical structure
Priority & Impact
- Priority: Medium-High (workflow improvement)
- Effort: Medium (requires memory system changes)
- Impact: High (addresses core workflow friction)
- Backward Compatibility: High (new opt-in behavior)
This feature would provide developers with the directory-scoped context control they expect while maintaining Claude Code's current hierarchical behavior as the default.
This issue has 7 comments on GitHub. Read the full discussion on GitHub ↗