[FEATURE REQUEST] Allow Claude Code to access gitignored files

I'd very much like this as well, though I wonder if an allowlist style would be less complicated, ie.,

.gitignore

tasks/

.claudeallow

tasks/

=> Claude will surface tasks/ things in autocomplete and automatically read them as necessary.

This way Claude can continue to reference .gitignore for ignored files, but then also allow files explicitly allowed in .claudeallow for use in autocomplete and file discovery / reading.

@nicksergeant Yeah, something like this. I think the main concern for everyone is the specs, tasks, plans whatever the folder with the specifications we don't want to commit and track but need for planning

+1

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/1304
2. https://github.com/anthropics/claude-code/issues/620
3. https://github.com/anthropics/claude-code/issues/579

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Update: This issue persists and shows inconsistent behavior

The Anthropic team claimed to have fixed the gitignore issues in #611, #1818, #2336, but they only fixed the dot-prefix (hidden files) issue, NOT the gitignore exclusion problem.

Current State:

1. Inconsistent behavior: Per #1373, Claude Code CAN read gitignored files with Read() but WON'T show them in @ autocomplete. This inconsistency is confusing and suggests the restriction is only partially implemented.

1. Strong community need:

• #1304 has 58+ 👍 reactions requesting .claudeignore
• #2305 (the original) had 57+ 👍 reactions
• Multiple duplicate issues keep being created (#620, #611, #1818, #2336)

1. Core design flaw: Claude Code conflates two orthogonal concerns:

• Version control (.gitignore): What should be shared with other developers
• AI tool access: What the AI should be aware of locally

Real-world Impact:

Developers cannot properly use Claude Code with:

• Local environment files (.env.local, .env.development)
• Personal notes and TODO files (tasks/, notes/)
• Local test data and fixtures
• Project-specific Claude instructions (CLAUDE.local.md)
• Any file that needs to stay out of version control but be accessible to the AI

The Ask:

Please don't close this issue without a proper solution. The community has been clear about the need, and the partial fix for dot-files shows you recognize there's a problem. We need either:

1. A .claudeignore file that overrides gitignore for Claude Code
2. Proper configuration in .claude/claude.json that actually works (currently broken per #1373)
3. At minimum, consistent behavior (if files can be read, they should be discoverable)

This has been an issue for 6+ months across multiple reports. The fact that issues keep being closed and recreated shows this is not resolved. Can we please get a proper resolution or at least an explanation of any technical limitations preventing this feature?

Related issues showing the scope of this problem:

• #611 (claimed fixed, but only for dot-files)
• #620 (security concerns with .env files)
• #1304 (58+ upvotes for .claudeignore)
• #1373 (shows the inconsistent behavior bug)
• #1818 (dot-directories in autocomplete)
• #2305 (original issue, closed without solution)
• #2336 (hidden files not shown)

Just to add, the opposite problem is real as well - eg. generated code is usually .gitignore'd though visible to developers – but since Claude respects .gitignore, it becomes quite dumb since it can't look up eg. any generated type definitions.

So there's a need to both ignore more and less.

+1 this.

Quite annoying not being able to access a personal specific file I'm using to aid development, just because I'm (properly, as per git etiquette) gitignoring it.

+1
.claude/ file can be @ -mentioned . It would be helpful when Claude Code user can optionally choose the setting files and others being autocompleted or not.

+1

+1

Imagine working on a cli tool which places logs in it's "bin" directory which is gitignored. You want CC to read the log when makeing a propmpt but you can't @reference the file and have to copy and paste the path manually. This is simply about convenience and this request will keep on re-appearing until this is implemented by the CC team. Matter of time really.

+1

If the files you want to ignore are not project specific, you can use global .gitignore. Fortunately Claude is not aware of this file, so it will be able to access files/folders ignored there and git won't show them as changes.

+1

+1

Please make that configurable though.

+1

Please fix this issue

+1

+1

Can people _please_ stop writing "+1" in the comments and click the 👍 in the original description instead?

Can people _please_ stop writing "+1" in the comments and click the 👍 in the original description instead?

I don't think an emoji reaction does as well of a job or noting continued interest (can't tell when someone reacted), I also don't think it should be either/or. Do both.

+1

Claude code should have absolutely ZERO interaction with the .gitignore file. Period. it's called .gitignore for a reason. It's for git. Nothing else.

A classic example of why this is a TERRIBLE idea is having a logs folder.

Obviously, this is something that I'd immediately add to .gitignore. But if I do that, I can't reference a log file. Which is obviously dumb.

I also don't agree with a .claudeignore or .claudeallow - this creates too much claude guff in a project root & adds unnecessary dev work.

You already have over-engineered settings ecosystem that uses scopes. Stick with that.

For projects: .claude/settings.json
For global (eww): ~/.claude.json I don't even understand the point of this especially when you have and appear to use ~/.claude/settings.json

that's not to mention the .claude/settings.local.json that sometimes appears too. Then you have the .mcp.json in the project root... CLAUDE.md in the project root...

IMHO you only need 2 scopes: Project and User/Global (done properly and contained within the ~/.claude/ folder, not spamming config rubbish all over a users home directory) and a single config file for each scope. This way, managing and maintaining a single settings schema becomes trivial which makes documentation easier, adds consistency and reduce the likelihood of issues like what's happening here (where logic interactions get missed).

1. Clean up and fix your settings ecosystem - as explained above, it's a mess.
2. Decide whether decoupling the agent tool permissions from interactive elements (like when using the @ symbol) is a good idea
3. Update the settings file to reflect accordingly

Imo the easy solution should be simple:

1. add option to settings.json: respectGitIgnoreFile: <bool> // Enable-Disable this behavior = everyone's happy
2. add option to settings.json: respectToolPermissions: <bool> // Make claude interactive elements also respect tool permissions. Example: if "deny":["Read(.venv/)"] is an option, then the @ symbol will also not reference files in this folder

The above is probably the simplest solution as it would keep everyone happy without introducing project breaking bugs. Certainly 1 needs to be the way forward for this, defaulting to true.

However it would probably just be easier to add the following to the settings.json > "claudeIgnore": [...]. You'll have to decide whether you want this 'decoupled behavior' between the interactive terminal mode and the tool permissions system

This isn't ideal imo though. I strongly disagree with the idea of having a tool that modifies its behavior based on files that it has no business depending on. Might be a hot take but i doubt it.

@hackyon-anthropic dunno if that makes sense but eh. Hopefully will see this changed soon, I'm finding it quite a nuisance

Agreed, having everything Claude centralized in the .claude folder would probably be the best experience.

And having an option inside the settings to turn the "use .gitignore" feature off would be great.

Supporting this request from a research workflow perspective. As an astrophysics researcher, I encounter this limitation daily with computationally expensive research outputs that are scientifically critical but storage-prohibitive for GitHub. For example, I have a stellar spectral library comprising thousands of flux files across nine chemical abundance grids, which represents months of computational work. These files are .gitignored solely for storage management (they are too large for free GitHub), not for relevance filtering. I need Claude Code to analyse trends across parameters, compare flux distributions between chemical compositions, and validate model outputs. The current behaviour assumes .gitignore = "not important for analysis," which breaks down in research contexts where .gitignore often means "too large for version control" rather than "not relevant." This creates a false choice between bloating repositories with large datasets or hampering AI assistance for our most important research outputs.

Just encountered this problem when my private memory banks carefully excluded from the repository by .gitignore (and pushed to a different private git) are completely ignored by CC. It's a nonsense - what my git workflow has to do with CC at all?

100% agree. This causes a massive headache, and I'm forever committing files to git that I hadn't intended because I had to remove them from .gitignore just to satisfy claude code.

It just seems so obvious how the current system is fundamentally broken for modern development workflows I'm staggered that a solution isn't already in place. I don't even care what sort of solution it is. I just want a solution so that I can use .gitignore just for git and something else for claude,

+1

+1 Probably the biggest pain point for me as i was Claude Code as a pair programmer and not just some agent in the cloud. It needs .claudeignore it can be with .claude.

A somewhat hacky workaround I've come up with is using a /commit command to explicitly unstage any files I don't want to accidently commit but want Claude to see.

commit.md

+1 -- settings.json already has section for excluding sensitive files. There is no reason for claude to ignore files listed in .gitignore by default, should be opt-in setting at most.

Excluding sensitive files To prevent Claude Code from accessing files containing sensitive information (e.g., API keys, secrets, environment files), use the permissions.deny setting in your .claude/settings.json file: `` { "permissions": { "deny": [ "Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)", "Read(./config/credentials.json)", "Read(./build)" ] } } `` This replaces the deprecated ignorePatterns configuration. Files matching these patterns will be completely invisible to Claude Code, preventing any accidental exposure of sensitive data.

Update: we've added the toggle within /config to allow showing all files in the picker including the gitignored ones!:D

Nice! Is that planned for 2.0.26?

Update - we had a public release this morning for v2.0.27 which contained the fix for this issue!

Is there a configuration setting available to set in JSON or with an environment variable?

@karenzhou-ant Is there a way to hide some files and directories along with using this new setting? Such as .git, node_modules, etc. Because now the search is really slow for some big projects

UPD: Managed to resolve by providing the custom .ripgreprc config with the needed settings. Thanks!

UPD: Managed to resolve by providing the custom .ripgreprc config with the needed settings. Thanks!

@npupko How did you set this up exactly? Where did you place the .ripgreprc? Did you set these flags somehow in your project?

  "env": {
    "RIPGREP_CONFIG_PATH": "${workspaceFolder}/.ripgreprc",
    "USE_BUILTIN_RIPGREP": 0
  }

Thanks for the effort @karenzhou-ant @hackyon-anthropic but this "Respect .gitignore in file picker" toggle is not a finished feature.

The current toggle creates an all-or-nothing situation: either respect ALL .gitignore rules or respect NONE. In practice, this means:
When enabled (default): Legitimately needed gitignored files are invisible, such as:

• notes/ or docs/local/ - Personal project documentation
• TODO.md - Personal task tracking
• .env.local - Local environment overrides you need to reference
• coverage/index.html - Test coverage reports you want to check
• Local scripts or configs you're iterating on

When disabled: The file picker becomes polluted with thousands of irrelevant files from node_modules, .next, dist, build, .cache, etc. For example:

• Trying to find a nested README.md in codebase requires scrolling through dozens of node_modules/*/README.md files
• Performance degrades significantly with large dependency trees

This is not what 99% users of this feature need. What we actually need is selective .gitignore overrides, not a global toggle.

Common use cases:

• "I want to see notes/*.md but NOT node_modules"
• "I want to see .env.local but NOT build artifacts"
• "I want to see coverage/ reports but NOT .next or dist"
• "I want to see my TODO.md but NOT .cache"

In its current state, this is a half-backed feature that satisfies nobody.

This issue has already received some suggestions that would solve this problem:

• .claudeignore file - Allow patterns like !tasks/ to selectively expose gitignored files
• .claudeallow file - Allowlist approach to explicitly permit specific gitignored files

Or something similar that solves the real problem.

Could we get this prioritized for a proper implementation?

I agree with @funkyOne , the current implementation is hacky at best. I've also noticed the degradation in performance when searching for files.

.claudeignore would be my preferred implementation as it would follow the same conventions as .gitignore, and as a result presumably be easier to implement.

.claudeignore is fine provided it's contained in settings.json. Claude spams way too many files. It's time for them to improve their entire settings ecosystem imo. 1 settings file per scope is all that's required.

I really don't want to see any more .ignore / .include / etc file 'spam'. There's too much project clutter as it is

.claudeignore is fine provided it's contained in settings.json. Claude spams way too many files. It's time for them to improve their entire settings ecosystem imo. 1 settings file per scope is all that's required. I really don't want to see any more .ignore / .include / etc file 'spam'. There's too much project clutter as it is

That's just your preference. I want a .claudeignore that follows conventions, similar to for example .dockerignore. It's not that uncommon. Keeping everything in one config file is a bad practice. Maybe just move the config files to .claude folder.

Update: we now support users specifying specific files/directorie to ignore using the --no-ignore-vcs flag instead of the --no-ignore flag. that way, users can still put stuff inside a .ignore file and that should be ignored by ripgrep.

@karenzhou-ant great, is there any documentation about it anywhere? Could not find anything in https://docs.claude.com/en/docs/claude-code/cli-reference

@karenzhou-ant , is this configurable only as a flag, or is it configurable by settings.json as well?

@luiz00martins @deviantony @funkyOne

This is now configurable through:

1. Disable "Respect .gitignore in file picker" in /config
2. Create a new .ignore file in the current directory and add the patterns you want ignored in the search
3. Profit 💯

This is now also supported in the VSCode extension. There's a separate config in the VSCode extension as well (although settings here aren't shared, and you'll need to disable the setting again in VSCode for it to work)

WARNING: Understanding that Claude may pick up on secrets, API tokens, etc in your .gitignored files if you disable the respect gitignore setting, so use this carefully!

Nice stuff!

One minor question: Was .ignore a typo for .claudeignore, or it that the correct name?

Should just be .ignore

Weird naming choice but thanks for the info!

That is a wierd choice of name, why not .claudeignore? Makes its purpose much clearer and consistent with existing .ignore files.

That said it does work well, thanks for implementing.

@luiz00martins @deviantony @funkyOne This is now configurable through: 1. Disable "Respect .gitignore in file picker" in /config 2. Create a new .ignore file in the current directory and add the patterns you want ignored in the search 3. Profit 💯 This is now also supported in the VSCode extension. There's a separate config in the VSCode extension as well (although settings here aren't shared, and you'll need to disable the setting again in VSCode for it to work) WARNING: Understanding that Claude may pick up on secrets, API tokens, etc in your .gitignored files if you disable the respect gitignore setting, so use this carefully!

Can this be done PURELY within .claude/settings.json? If so how? I don't want to add .ignore to every project

Can this be done PURELY within .claude/settings.json? If so how? I don't want to add .ignore to every project

Any update on this? This feels like a pretty terrible solution if not. I don't want to disable .gitignore across the board, I want to explicitly enable / disable indexing on a per project basis by exception. This approach (seemingly) forces me now to decide between unexpected results in every single project so that I can deal with an exception in one.

Is this the intended behaviour?

"Terrible solution" feels like an overstatement. As far as I'm seeing, you could keep the setting enabled globally, and only disable in projects where you have a .ignore file set up.

However, yes, it'd be nice to have this configurable on settings.json instead. I feel like it'd give the ability to configure per-project and globally for free (as per the natural of Claude Code's settings.json, which can be configured globally, or per project).

You could keep the setting enabled globally, and only disable in projects where you have a .ignore file set up.

@luiz00martins perhaps I have misunderstood how this has been implemented then. I understood from what's been documented (and what I tested) that you enable/disable it in /config section of Claude Code, whcih means that setting is global.

What do you mean by "only disable in projects where you have a .ignore file set up"? How is that possible if this is not configurable in settings.json?

@luiz00martins any final thoughts?

I have a deps folder that contains many folders that is updated frequency. Of those, I'd like claude to ignore all but one of them. This pattern worked in .gitignore but doesn't seem to work in .ignore, with the entire deps folder being ignored.

/deps
!/deps/special-dep

Is this intended behavior? Is there another way of achieving this goal I should try?

@mattheworiordan I now think _I_ may have misunderstood the settings structure.

It was my understanding that every one of the global configurations was present in the root settings.json for claude. In that case, you would set up your global configuration to true, and every project that has a .ignore file, you would set up the configuration to false in that project's settings.json.

However, I have just looked at my settings.json file, and this setting doesn't seem to be present in there. So I guess I was mistaken.

If that's the case, then I also find this solution very unsatisfactory.

开发中

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.

Just submitted a change to add per-project setting for this one, so you can add "respectGitignore": false to settings.json or settings.local.json and have this setting be applied locally. Should be available later in the week!

for those who want to ignore everything in a directory except certain exclusions, you can try to add something like this to your .ignore:

node_modules/*
!node_modules/donotignore/