[FEATURE] Allow projects to exclude inherited .claude/rules/ from parent directories

Resolved 💬 7 comments Opened Mar 14, 2026 by poodle64 Closed May 25, 2026

Preflight

  • [x] I have searched for existing feature requests
  • [x] This is a single feature request (not multiple features)

Problem Statement

Claude Code traverses parent directories and loads .claude/rules/ from every ancestor. There is no mechanism to exclude or filter inherited rules at the project level.

This is a significant problem for monorepo and multi-project setups where a parent directory contains shared governance rules. Sub-projects inherit the entire rule set regardless of relevance.

Our setup: A master governance project containing ~28 rule files (~3,728 lines) covering Python, Svelte, TypeScript, Rust, Swift, security, infrastructure, etc. Sub-projects live inside this tree (e.g. repos/godswood/). Every sub-project loads all 28 rules at session start, even if the project only uses Python + Svelte.

What we tried (and what failed):

  1. paths: frontmatter scoping — Intended to load rules only when matching files are touched. However, #32057 (still open) causes path-scoped rules to be re-injected as <system-reminder> blocks on every tool call, consuming ~46% of the 200K context window after ~20 tool calls. We had to strip all paths: frontmatter as a workaround.
  1. Selective symlinks — Replaced the single master/ directory symlink with individual symlinks to only relevant rule subdirectories (e.g. symlink python/ and svelte/ but not rust/ or swift/). This doesn't work because Claude Code loads rules from the parent directory's .claude/rules/ regardless of what's symlinked in the child project.
  1. Removing the symlink entirely — Deleted the master symlink from the sub-project's .claude/rules/, leaving only project-specific rules. All 28 parent rules still loaded via parent directory traversal. Confirmed with a canary rule test.
  1. Rule consolidation — Merged 44 rule files down to 28 to reduce overhead. Helps marginally but doesn't solve the inheritance problem.

Quantified impact:

| Project Type | Irrelevant Rules Loaded | Wasted Lines |
|---|---|---|
| Python-only CLI | svelte/, typescript/, rust/, swift/ | ~896 lines (24%) |
| Swift-only app | python/, svelte/, typescript/, rust/ | ~1,259 lines (34%) |
| Rust-only tool | python/, svelte/, typescript/, swift/ | ~1,330 lines (36%) |

Proposed Solution

A project-level mechanism to exclude specific inherited rules from parent directories. Possible implementations:

  • A .claude/rules/.exclude file listing glob patterns to ignore from ancestors (e.g. master/rust/, master/swift/)
  • A rulesExcludes setting in .claude/settings.json (analogous to the existing claudeMdExcludes for CLAUDE.md files)
  • A discovery_mode frontmatter field on rules (as proposed in #29915)
  • A stop_traversal: true flag in a project's .claude/settings.json to prevent loading rules from parent directories entirely

Any of these would work. The key requirement is that a sub-project can control which ancestor rules it inherits.

Alternative Solutions

The only working alternative we've found is to move language-specific rules out of .claude/rules/ entirely (e.g. into governance/rules/) so they don't auto-inherit, then have sub-projects symlink back selectively. This works but breaks the intended convention and makes the rule setup non-obvious to collaborators.

Priority

Medium

Feature Category

Config

Additional Context

Relationship to other issues:

  • #32057 — paths: re-injection bug. If fixed, would help with per-file-type filtering but would NOT solve per-project inheritance exclusion
  • #20880 — Requests exclusion for parent CLAUDE.md files. This issue covers the same problem for .claude/rules/ files
  • #29915 — RFC proposing discovery_mode for traversal control. Would solve this if implemented
  • #16600 — Git worktree traversal boundary. Related traversal scope issue

Claude Code version: 2.1.75
Platform: Anthropic API (Claude Max)
OS: macOS 15.3.2

View original on GitHub ↗

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