Ancestor CLAUDE.md files do not process @imports; @../ paths never resolve

Environment: Claude Code 2.1.226, macOS 14.6 (arm64), tested via claude -p (model-independent — behavior reproduces regardless of model)

Summary

The memory docs state: "Relative paths resolve relative to the file containing the import, not the working directory." Two observed behaviors contradict this:

1. When a CLAUDE.md is loaded as an ancestor memory file (session launched in a subdirectory), its @import lines are silently skipped entirely — the file's own text loads, the imported content does not.
2. An import path containing .. (e.g. @../AGENTS.md) is silently ignored even in the working directory's own CLAUDE.md, whether resolved relative to the file or the cwd (both point at an existing file in the repro).

Reproduction

mkdir -p /tmp/import-repro/sub && cd /tmp/import-repro
echo 'The magic word from AGENTS.md is ZEBRA-42.' > AGENTS.md
printf '@AGENTS.md\n\nThe magic word from CLAUDE.md is PELICAN-77.\n' > CLAUDE.md

# Test 1 — session at the root: import works
claude -p "Which magic words are in your loaded project instructions?"
# => PELICAN-77 and ZEBRA-42  ✅

# Test 2 — session in the subdirectory: ancestor import skipped
cd sub
claude -p "Which magic words are in your loaded project instructions?"
# => PELICAN-77 only  ❌ (docs say @AGENTS.md should resolve relative to /tmp/import-repro/CLAUDE.md)

# Test 3 — parent traversal in the cwd's own CLAUDE.md: never resolves
printf '@../AGENTS.md\n' > CLAUDE.md
claude -p "Which magic words are in your loaded project instructions?"
# => PELICAN-77 only (ancestor text) ❌ — ZEBRA-42 absent under either resolution rule

Expected: ZEBRA-42 present in tests 2 and 3, per the documented resolution rule.

Why it matters

The docs recommend @AGENTS.md inside CLAUDE.md as the interop pattern with the cross-tool AGENTS.md standard. That pattern silently loses the repo's entire shared instruction set for any session launched below the repo root — and for a workspace/monorepo root CLAUDE.md (always loaded as an ancestor by nested-project sessions), the import never fires at all. We migrated a 13-repo suite to the @AGENTS.md pattern, hit this, and had to fall back to ln -s AGENTS.md CLAUDE.md symlinks, which work correctly in all the same cases.

If ancestor import-skipping is intentional (e.g. a security decision), a docs note plus a warning when an ancestor file contains import syntax would prevent silent context loss; the .. restriction likewise deserves documentation.