[BUG] paths: frontmatter in user-level rules (~/.claude/rules/) is ignored

[ucuc]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Rules with paths: frontmatter placed in user-level rules directory (~/.claude/rules/) are never loaded, even when working with files that match the specified glob patterns.

Setup:

• User-level rule file: ~/.claude/rules/csharp-dotnet.md with paths: ["**/*.cs"] frontmatter
• Project has .cs files

Observation:

• When editing .cs files, the user-level rule with paths: is NOT loaded
• The same rule file works correctly when placed in project-level rules (./.claude/rules/)
• The same rule file also works when symlinked from user-level to project-level rules
• Rules without paths: frontmatter in ~/.claude/rules/ load correctly (unconditionally)

Verified behavior:

Location	paths: frontmatter	Result
~/.claude/rules/	With paths	❌ Not loaded
./.claude/rules/	With paths	✅ Loaded
./.claude/rules/	Symlink to user-level	✅ Loaded

What Should Happen?

User-level rules with paths: frontmatter should be loaded when working with files that match the specified glob patterns, just like project-level rules.

According to the documentation:

User-level rules: You can create personal rules that apply to all your projects in ~/.claude/rules/

The paths: frontmatter should work consistently regardless of whether the rule is placed in user-level or project-level rules directory.

Error Messages/Logs

No error messages. The rules are silently not loaded. Running `/memory` shows the user-level rule with `paths:` is not listed in the loaded memory files.

Steps to Reproduce

1. Create a user-level rule file with paths: frontmatter:

   mkdir -p ~/.claude/rules
   cat > ~/.claude/rules/csharp-rules.md << 'EOF'
   ---
   paths:
     - "**/*.cs"
   ---
   
   # C# Rules
   
   - Follow C# naming conventions
   EOF

2. Create a project with a .cs file:

   mkdir test-project && cd test-project
   echo 'public class Test { }' > Test.cs

3. Start Claude Code: claude

4. Run /memory - observe that csharp-rules.md is NOT listed

5. Edit the .cs file: ask Claude to "Read Test.cs"

6. Run /memory again - the rule is still NOT loaded

7. Workaround test: Copy the same rule to project-level:

   mkdir -p .claude/rules
   cp ~/.claude/rules/csharp-rules.md .claude/rules/

8. Restart Claude Code and edit the .cs file

9. Run /memory - now the rule IS loaded

This confirms paths: works in project-level rules but not in user-level rules.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.25

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

Workaround:
Using symlinks from project-level rules to user-level rules works:

# In project directory
mkdir -p .claude/rules
# On Windows (requires admin):
mklink ".claude\rules\csharp-rules.md" "C:\Users\username\.claude\rules\csharp-rules.md"
# On macOS/Linux:
ln -s ~/.claude/rules/csharp-rules.md .claude/rules/

Related issues:

• [BUG] Path-scoped rules in .claude/rules/ not automatically loaded when working with matching files #16853 - Path-scoped rules in .claude/rules/ not automatically loaded (project-level)
• Documentation: .claude/rules/ frontmatter format incorrect - globs works, paths with quotes/YAML list does not #17204 - Documentation: frontmatter format issues

This issue is different from the above as it specifically affects user-level rules (~/.claude/rules/), not project-level rules.

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Path-scoped rules in .claude/rules/ not automatically loaded when working with matching files #16853
2. Documentation: .claude/rules/ frontmatter format incorrect - globs works, paths with quotes/YAML list does not #17204
3. [DOCS] paths: frontmatter syntax in rules files is incorrect #19377

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[ucuc]

Additional finding: Inconsistent behavior after context compaction

I discovered another inconsistency related to this issue:

Before context compaction

• User-level rules with paths: frontmatter are not loaded (as reported above)
• /memory correctly shows they are not loaded

After context compaction

• When Claude Code performs context compaction (automatic summarization when context gets too long), the user-level rule files are read during the compaction process
• The rule content gets included in the summary and becomes part of the context
• However, /memory still shows the rules are not loaded

Result

• Before compaction: Rules with paths: are not applied (expected based on current buggy behavior)
• After compaction: Rules appear to be applied (included in context via summary), but /memory doesn't reflect this

This creates an inconsistent state where:

1. The rules are silently included after compaction
2. /memory doesn't accurately show what's actually in the context
3. The behavior differs depending on whether a compaction has occurred

This suggests the compaction process reads all rule files unconditionally, bypassing the paths: filtering logic.

[spawnia]

This may not be a separate bug from #19377.

I had user-level rules in ~/.claude/rules/ with paths: frontmatter using YAML array syntax, and they were not loading — which led me to believe user-level paths were ignored entirely.

After converting from YAML array syntax to CSV format, user-level path-conditional rules work correctly:

Before (not loading):

---
paths:
  - "**/*.tf"
  - "**/*.tfvars"
---

After (loading correctly):

---
paths: "**/*.tf,**/*.tfvars"
---

Verified output:

Loaded ../../wsl/dotfiles/.claude/rules/terraform.md

So user-level paths: frontmatter does work — the broken YAML array parsing (#19377) just made it appear otherwise.

[Johntycour]

Cross-reference: Root cause identified in #19377

This issue shares the same root cause as #19377 and #17204.

Root Cause

The paths: field in user-level rules is processed through _9A(), a CSV parser that expects a string input. When YAML list syntax is used, yaml.parse() returns a JavaScript Array, but _9A() iterates array elements instead of characters — producing concatenated globs without separators that match nothing.

Additional Issue: Quoted Strings

Per #17204 testing, even a single quoted paths: value fails:

• paths: **/*.cs (unquoted) → ✅ Works
• paths: "**/*.cs" (quoted) → ❌ Fails

This suggests the paths: field may strip or mishandle quotes differently than globs:.

Proposed Fix

See my detailed comment on #19377 with the complete call stack trace and one-line fix proposal.

Current Workaround

Use globs: instead of paths: in CSV format:

globs: "**/*.ts,**/*.tsx"

Note: paths: with YAML array syntax is documented in the official docs but does not work.