VS Code extension ignores external @imports in project CLAUDE.md (terminal loads them)

I was just about to report the same issue. I used Canary phrases instead of Markers, but same result.

I found adding this to my user CLAUDE.md allowed project level imports to function the same as in terminal:

@ Import Resolution (VS Code Extension Compatibility)

At the start of EVERY session, before responding to the first user message:

1. Check if project CLAUDE.md files in your loaded context contain lines starting with @ followed by a file path
2. If found, read each imported file immediately (resolve ~ as C:\Users\Name\)
3. Recursively follow any @ imports in those files (max 5 levels deep)
4. Apply inclusion rules from imported file frontmatter:

• inclusion: always — always apply
• inclusion: fileMatch with fileMatchPattern — apply only when working on matching files

When the user asks for canaries: Include canaries from all imported files you've loaded.

This ensures the VS Code extension behaves like the terminal version, which auto-loads @ imports. Without this, the VS Code extension ignores @ import directives.

Reproduced on macOS, so this isn't Windows-only. Claude Code 2.1.296, VS Code extension current as of 2026-10-13.

Repro: a project CLAUDE.md containing one line, @~/import-probe-target/marker.md, where that file lives outside the project and is imported by nothing else.

Terminal (claude in the project folder): the "Allow external CLAUDE.md file imports?" dialog appears at launch, before the first prompt. After approving, /memory lists the file as @-imported under Project instructions, and ~/.claude.json gets hasClaudeMdExternalIncludesApproved: true and hasClaudeMdExternalIncludesWarningShown: true for the project.
VS Code panel, same folder, fresh chat, _before_ the terminal approval: no dialog at any point, /context does not list the file under Memory files, the model only knows the file's content if it reads it with a tool, and no project entry is written to ~/.claude.json at all.

Workaround (dirty but confirmed)
VS Code panel, after the terminal approval: a new chat lists the file under Memory files and the import loads. It costs one claude CLI approval per project but any VS Code panel that opens in that project after will honor the import approval.

So the panel honors the per-project approval flag; it never presents the dialog, and never writes the never-asked state either. A developer who only uses the panel has no path to approval except a terminal session in the same folder. Worth noting for anyone hitting this: the terminal dialog's default selection is "No, disable external imports", so Enter declines, and a decline is sticky.

Same issue here, in a Dev Container on Windows 11. Adding my case since the setup is different from the Windows/macOS reports above.

Environment

• Host: Windows 11 → WSL2 (kernel 6.18.54.1-microsoft-standard-WSL2) → Docker Dev Container (Linux, user node)
• VS Code extension: anthropic.claude-code-2.1.296-linux-x64 (installed in the container's ~/.vscode-server/extensions)
• CLI in container: 2.1.197 (npm global)
• ~/.claude/ is bind-mounted from the Windows host (H:\Programing\ClaudeCode\.claude, 9p)

Paths

• Project: /workspaces/obsidian-eagle/CLAUDE.md
• Content: @/home/node/.share/instructions/test.md (absolute path, outside the project → external import)

What I observed

1. In the VS Code panel, the external import is never expanded. The CLAUDE.md content reaches the model as the literal @/home/node/.share/instructions/test.md line.
2. No approval dialog is ever shown in the panel.
3. Adding the entry manually fixed it:

```json
"/workspaces/obsidian-eagle": {
"hasClaudeMdExternalIncludesApproved": true,
"hasClaudeMdExternalIncludesWarningShown": true
}

After that, claude -p in the project loads the import, and a new VS Code panel session also loads it.

This matches @msuter-cbre's finding: the panel honors an existing approval but never asks for one. In a Dev Container this happens again for every new project, and because ~/.claude.json sits in a volume that isn't visible from the host, users are unlikely to find the flag on their own.

Expected: the panel shows the same approval dialog as the terminal, or there is a user-level setting to approve external imports for all projects.

Investigated and written up with Claude Code (Opus 5.5).