"@file Import Fails for Global CLAUDE.md Instruction Files"

[LouD82]

Bug Description The import feature for CLAUDE.md files appears to be functioning inconsistently. While @file imports work properly in project-level CLAUDE.md files, they fail when used in the global instructions file (~/.claude/CLAUDE.md). When attempting to import system instructions with "@~/.claude/system-instructions.md", Claude doesn't recognize the content, and the imported file doesn't appear in the /memory output despite documentation stating it should. This suggests a potential permissions issue or bug specific to global instruction imports, as the same syntax works correctly in project-specific contexts.

Environment Info

• Platform: macos
• Terminal: Apple_Terminal
• Version: 0.2.107
• Feedback ID: e1883750-c156-49d8-9901-283fe8375b44

[LouD82]

After tonight's update, everything started working great once I approved the use of imports at the PROJECT level via the dialog that comes up the first time you do that. Prior to that, none of the global imports were working, but after, everything is working perfectly even though the dialog pertained to project level instructions, not the global instructions.

[notImposterSyndromeIfImposter]

I'm actually seeing a similar issue. Global imports don't work in project using the @ nomenclature. Steps to reproduce.

1. Open up claude in a non-git/project
2. Ask it what it knows about something stored in a @ path. If it's relevant I'm using @~/.claude/memory/file.md
3. It recognizes it and tells me what I expect. Same with any direct memory in the CLAUDE.md
4. cd to a project/git repo. Call claude.
5. repeat above, it cannot auto-load my @path. I get no such project dialogs.

[LouD82]

Think I got this figured out. Here is the full description and workaround in case it helps anyone else:

Description

When starting Claude Code in a new project, the "hasClaudeMDExternalIncludesApproved" setting in ~/.claude.json is set to false, but the approval dialog that should appear to let users enable this feature never shows up. This prevents external includes in CLAUDE.md files (using @ syntax) from working properly.

Steps to reproduce

1. Create a new project directory
2. Start Claude Code in this directory
3. Create a CLAUDE.md file with @imports (e.g., "@path/to/file.md")
4. Notice that Claude can't access the content from the imported files there or your global CLAUDE.md instruction file (if you have imports set up there)

Workaround

Manually edit ~/.claude.json to set "hasClaudeMDExternalIncludesApproved": true for the project entry.

Expected behavior

Claude should either automatically set "hasClaudeMDExternalIncludesApproved" to true for new projects or reliably show the approval dialog to let users enable this feature.

[modelD-svg]

I can't get this to work with the global memory on WSL with v1.0.6. Not natively and also not with the workaround. Maybe I'm missing something:

I have the memory file at ~/.claude/CLAUDE.md. Claude, without reading files, can recall the .md, but the imported instructions are not resolved. Here's claudes response:

● Yes, in the system reminder context I was given, there is a mention of "general.md". It appears in the CLAUDE.md
  file contents where it shows:

  # General Instructions
  @~/.claude/general.md

I added hasClaudeMDExternalIncludesApproved": true for the project in which I started claude to the ~/.claude.json.

The /memory command also shows the same as claudes response. The docs use this exact scenario as an example:

# Individual Preferences
- @~/.claude/my-project-instructions.md

The only difference is probably that this example is used in the project memory, while I'm trying to do it for the user memory.

[LouD82]

Did you have to ADD "hasClaudeMDExternalIncludesApproved": true to the project entry, or was it already there and set to false? It should already be there and set to false, and setting it to true is the fix. If you want, post some or all of your ~/.claude.json and I'll take a look.

[modelD-svg]

TLDR: Manually adding "hasClaudeMdExternalIncludesApproved": true, (notice the lower capital d) to my project entry in ~/.claude.json made the user context file import work (for me).

---

Did you have to ADD "hasClaudeMDExternalIncludesApproved": true to the project entry, or was it already there and set to false? It should already be there and set to false, and setting it to true is the fix. If you want, post some or all of your ~/.claude.json and I'll take a look.

I did have to add it. I can't post my claude.json, but heres some random greps:

me:/mnt/c/$ cat ~/.claude.json | grep "hasClaudeMD"
      "hasClaudeMDExternalIncludesApproved": true,
      "hasClaudeMDExternalIncludesApproved": true,

me:/mnt/c/$ cat ~/.claude.json | grep "allowedTools\":"
      "allowedTools": [],
      "allowedTools": [
      "allowedTools": [
      "allowedTools": [
      "allowedTools": [],
      "allowedTools": [
      "allowedTools": [],
      "allowedTools": [
      "allowedTools": [
      "allowedTools": [
      "allowedTools": [
      "allowedTools": [
      "allowedTools": [
      "allowedTools": [
      "allowedTools": [
      "allowedTools": [
      "allowedTools": [
      "allowedTools": [
      "allowedTools": [
      "allowedTools": [
      "allowedTools": [
      "allowedTools": [
      "allowedTools": [
      "allowedTools": [
      "allowedTools": [
      "allowedTools": [],
      "allowedTools": [
      "allowedTools": [
      "allowedTools": [],
      "allowedTools": [],
      "allowedTools": [],
      "allowedTools": [],
      "allowedTools": [
      "allowedTools": [
      "allowedTools": [
      "allowedTools": [],
      "allowedTools": [],
      "allowedTools": [
      "allowedTools": [],
      "allowedTools": [
      "allowedTools": [],
      "allowedTools": [],
      "allowedTools": [],
      "allowedTools": [],
      "allowedTools": [],
      "allowedTools": [],
      "allowedTools": [],

Out of all projects I have initialized on this machine (many of which I have used over the past 4 weeks or so, only a single one had hasClaudeMDExternalIncludesApproved. There, it was set to true. The other occurence I added manually. The project in question is one I have last worked on 27 days ago. In the meantime, there have been at least 5-10 projects (probably more) that I had open in claude, without the parameter being added. Edit: Looking back, its more probable that I added this one by accident in the wrong project.

I did some more debugging and moved my old ~/.claude.json, reauthenticated and opened claude in a project. I was then able to see the following two params added to the newly created fresh config:

      "projectOnboardingSeenCount": 0,
      "hasClaudeMdExternalIncludesApproved": false,
      "hasClaudeMdExternalIncludesWarningShown": false,
      "exampleFiles": [

After moving back to the old config and setting "hasClaudeMdExternalIncludesApproved", claude seemed to get the correct memory, with the context from the file I imported. /memory still showed the unresolved path. Makes sense for this to be intentional – tho it would be nice to have confirmation of correctly imported files without having to quiz claude about its internal context.

Switching the d to uppercase made it not work again!

After having played around with this for a while, I have seen the two parameters added to more projects now – not all, but some. Cannot see a pattern in the projects that have it and the ones that don't. Seems to be there are some bugs left to be squashed here.

[modelD-svg]

Also, if claude is to be trusted here, the files seem to be provided separately, not as I thought, with the imports resolved:

● Yes, the general.md file was provided separately. In the context, I can see:

  1. First, there's Contents of /home/user/.claude/CLAUDE.md which contains just the reference @~/.claude/general.md
  2. Then separately, there's Contents of /home/user/.claude/general.md which contains the full detailed instructions

  So the system provided both files - the CLAUDE.md file that references general.md, and then the actual contents of general.md itself. This allows the
  CLAUDE.md to use a simple reference (@~/.claude/general.md) while the system ensures I have access to the actual content by providing it separately.

As such, one has to be careful about phrasing when asking about context file contents. However, this wasn't the reason for my earlier problems, as I always asked about the context generally, not specific files.

[jkp]

This is still not working for me - i can only make the references work in the project memory file - changing those keys has no effect on reading files referenced from my user memory.

[LouD82]

Changing the keys works for me (but yes, it's still broken as I have to do this every time I start a new project). But this workaround does work every time (at least on Mac and Linux). Make absolutely sure your project looks like this in ~/.claude.json

    "/path/to/project": {
      "allowedTools": [],
      "history": [],
      "dontCrawlDirectory": false,
      "mcpContextUris": [],
      "mcpServers": {},
      "enabledMcpjsonServers": [],
      "disabledMcpjsonServers": [],
      "hasTrustDialogAccepted": false,
      "projectOnboardingSeenCount": 1,
      "hasClaudeMdExternalIncludesApproved": true, #KEY LINE
      "hasClaudeMdExternalIncludesWarningShown": false
    }

Before changing hasClaudeMdExternalIncludesApproved (make sure it's a lowercase d in Md as I messed this up before) to true, CC will look like this when you enter /memory:

After, it should look like this (with whatever @file.md you have set up in place of mine):

[modelD-svg]

Changing the keys works for me

Same for me, I just verified this behavior with 1.0.18 again on wsl. Setting hasClaudeMdExternalIncludesApproved has a direct effect on whether the imports are evaluated.

Maybe you can share your project json and memory files with their paths to help debug (with anything unrelated removed).

Also sad to see this still not fixed as the feature is mostly working as intended from what I can tell – claude would just have to prompt whether to resolve the imports and set the boolean.

[github-actions[bot]]

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.