--setting-sources project still loads user memory (~/.claude/CLAUDE.md and ~/.claude/rules/*.md)

Environment

• Claude Code 2.1.234, macOS (darwin 25.3.0)
• Auth: subscription OAuth (keychain)

Expected

Per the CLI reference and the Agent SDK docs, --setting-sources project loads only project-level files. The v2.1.223 changelog also states "Nested .claude/rules/*.md files now respect --setting-sources". So a spawn with --setting-sources project should exclude user-level memory: ~/.claude/CLAUDE.md and ~/.claude/rules/*.md.

Actual

Both still load. Repro (content-probe, not listing-probe, so it can't be a hallucinated file list):

1. Put a distinctive marker string in ~/.claude/CLAUDE.md (e.g. USERMEM-CANARY-1) and another in an always-load ~/.claude/rules/foo.md (USERRULE-CANARY-2).
2. From any project directory:

``
echo "Without using tools: does your loaded context contain the exact string USERMEM-CANARY-1? And USERRULE-CANARY-2? Answer yes/no each." | claude -p --setting-sources project
``

1. Both answer yes. Same result with and without --add-dir, so it is not an add-dir interaction.

What IS correctly excluded under --setting-sources project (verified the same way): ~/.claude/skills discovery, user-settings hooks, and auto-memory (~/.claude/projects/<slug>/memory/MEMORY.md). Only the memory files (CLAUDE.md + rules/*.md) ignore the flag.

Why it matters

Systems that spawn scoped subprocesses with --setting-sources project (fenced sub-agents with per-directory context) get the user's entire global operating manual injected into every subprocess — in our case ~47KB per spawn that the flag is documented to exclude, including personal-context instructions that shouldn't reach subprocesses that process untrusted scraped content. --bare is not a workaround: it also disables project CLAUDE.md loading and keychain auth.

Suspected scope

Either user CLAUDE.md/rules memory loading was never wired to --setting-sources (docs bug), or the v2.1.223 change regressed. Happy to run any diagnostic build.