[BUG] @import (@path syntax) does not inline target file content into model context

Description

@path import syntax in CLAUDE.md (or any file read by Claude Code) does not inline the target file's content into the model's context, for either a subagent or a fresh top-level headless session. This contradicts the documented behaviour (imports supporting up to 4 hops of recursion) and silently drops all imported content with no error or warning.

Environment

• Claude Code CLI: 2.1.210 (finding made on this version; confirmed still present on 2.1.211 as of filing)
• OS: macOS
• Repro context: a real Obsidian vault repo with CLAUDE.md at the root

Repro steps

1. In a project's CLAUDE.md, add a line like @path/to/target-file.md.
2. Write a unique, distinctive marker string somewhere in the body of path/to/target-file.md (e.g. MARKER-STRING-a1b2c3).
3. From a fresh session in that same directory, ask (with tool use forbidden, so the model can't just go read the file itself): "Does your already-loaded context contain MARKER-STRING-a1b2c3? Don't use any tool."
4. As a control, in the same invocation, ask a question whose answer depends only on CLAUDE.md's own literal body (not an imported file) - confirms the harness is genuinely loading CLAUDE.md and the test methodology is sound.

Expected

The model reports the marker string is present (imported content is inlined into context), and the control question also passes.

Actual

• The control question passes - CLAUDE.md's own literal body is loaded correctly.
• The marker string is reported as not present - the @imported file's content never reached the model's context.
• Tested two ways, same result both times:
• Two independent Task-tool subagents, each asked the marker question with tool use forbidden.
• An independent headless claude -p "..." invocation (a genuinely separate process, not a subagent, run from the same project directory) with tools forbidden.

So this isn't a subagent-specific quirk - a completely fresh top-level session run non-interactively via claude -p shows the identical failure.

Why this matters

The documented behaviour ("imports support up to 4 hops of recursion") implies @import is a real content-delivery mechanism, and it's reasonable to build a project's context-loading design around it (e.g. splitting a large CLAUDE.md into smaller files that get pulled back together via imports). In our case that turned out to be a silent, total content-loss failure mode with no error surfaced anywhere - the import line just does nothing, and there's no way to tell from the session itself that anything is missing. We caught it only by deliberately instrumenting a test; without that, we'd have shipped a project relying on @import for real content delivery and never noticed the content wasn't there.

Notes

• Not yet tested: a genuinely interactive (non--p) session - based on the matched control passing identically in both the subagent and headless cases, we judge it unlikely to behave differently, but haven't directly confirmed it.
• We worked around this entirely by switching to native .claude/rules/*.md (which auto-load correctly, confirmed via the same marker-based test) rather than relying on @import for real content delivery.