[FEATURE REQUEST] Allow Claude Code to access gitignored files

[npupko]

Current Behavior

Claude Code currently respects .gitignore files and excludes gitignored files from:

• @-mention autocomplete suggestions
• General file awareness and reading (unless explicitly requested)

Problem Description

This behavior creates friction for local development workflows where users want to:

• Keep certain files out of version control (private notes, local configs, etc.)
• Still have Claude Code access these files for development assistance
• Avoid committing sensitive or personal files to public repositories

Use Case Example

I maintain a local tasks/ folder with markdown files containing project notes and TODOs. These files are:

• Gitignored to keep them out of the public repository
• Useful for Claude Code to reference when providing development assistance
• Currently inaccessible via @-mentions, making the workflow cumbersome

Proposed Solution

Introduce a .claudeignore file that works similarly to .gitignore but specifically controls Claude Code's file awareness:

• Override gitignore: Allow patterns like !tasks/ to make gitignored files visible to Claude Code
• Additional exclusions: Support standard ignore patterns to exclude files from Claude Code even if they're tracked by git
• Precedence: .claudeignore rules should take precedence over .gitignore for Claude Code's file handling

Example .claudeignore configuration:

# Make tasks folder visible to Claude Code despite being gitignored
!tasks/

# Exclude specific files from Claude Code even if tracked by git
*.log
temp/

Alternative Solutions

1. Command-line flag: --include-gitignored to override gitignore behavior globally
2. Config file option: Setting in Claude Code's configuration to control gitignore respect
3. Environment variable: CLAUDE_RESPECT_GITIGNORE=false for session-based control

Benefits

• Maintains security by keeping sensitive files out of version control
• Improves local development experience with Claude Code
• Provides granular control over file visibility
• Follows familiar patterns (similar to .gitignore syntax)

Impact

This would significantly improve the local development workflow for users who need to reference private/local files while keeping them out of version control.

[hesreallyhim]

Please let me know if you disagree, but it also ignores all dot-files, even if they are git-committed.

[vladrpmd]

This is strange. I was able to instruct claude to modify.env and.env.local files which are git ignored

[hesreallyhim]

@vladrpmd oh my mistake I was speaking directly about the @-mention functionality, I haven't had a problem with it not being able to access git-ignored stuff if told directly, i guess i haven't noticed it otherwise

[npupko]

@vladrpmd It's indeed possible to modify them, but they will not be taken into account unless you explicitly ask Claude Code to do so. And you will not be able to use autocomplete for that

[hesreallyhim]

@npupko

they will not be taken into account unless you explicitly ask Claude Code to do so.

Unless I misunderstand you, this is a general "feature" of Claude Code - it is not aware of anything that happens to the codebase unless it makes the change itself or you inform it of the change. If it's already read a file, it will not be aware if that file changes until it tries to touch it again.

[npupko]

@hesreallyhim You’re absolutely right. It doesn’t automatically track changes to the codebase unless it’s directly involved or explicitly informed. However, the issue I’m describing is a bit different from that general file awareness behavior. What I’m specifically talking about is the initial discovery and availability of files for @-mention autocomplete and general file reading capabilities.

Here’s the distinction:

Current .gitignore behavior:

• Gitignored files are completely excluded from Claude Code’s initial file discovery
• They won’t appear in @-mention autocomplete at all
• You have to explicitly reference them by full path if you want Claude Code to access them

General file awareness behavior (what you’re referring to):

• Claude Code reads files when needed but doesn’t continuously monitor for changes
• If a file changes externally, Claude Code won’t know until it reads the file again
• This applies to ALL files, whether gitignored or not

The .claudeignore proposal is specifically about that first issue - making certain gitignored files discoverable and available for @-mention autocomplete, while still keeping them out of version control.

[rasmusulriksen]

+1

[seanrea]

+1 to this. I was using Claude to author some unit tests and increase code coverage. It asked for access my coverage report which included in .gitignore. I had to temporarily remove that directory from .gitignore in order for autocomplete to "see" them.

[thomascgray]

+1 This would be ideal for me based on the number of repos I work in.

I often keep a file called NOTES.txt, several directories deep, when I'm working on projects I haven't touched in a while. It would be a huge boost for to me to be able to directly tell Claude "please look at my notes at @src/foo/bar/NOTES.txt" when I want it to do some work on a particular feature on a particular repo.

[tnederlof]

+1 I keep *_TODO.md in my .gitignore so I don't commit my various planning documents but this has the side effect of not being referencable by using @ which is a shame.

[j-0rdon]

+1

[Reuben1987AI]

+1

[alex-orlovskyi]

++

[joshwand]

I use repomix to package documentation into a single file to ensure its entirety is always read into context.. I put the repomix-output.md in .gitignore so I don't inadvertently commit it, but that means I have no way of forcing Claude Code to read the entirety of my documentation (since it's broken up into a bunch of files, tool-use doesn't always read everything like I want it to).

A command-line flag or some other kind of config to allow @'ing .gitignored files would be great. (In Cursor I have the same problem but I can at least manually drag it from the file explorer into the chat.)

[Galaxy-Husky]

+1

[nathaniel-fargo]

+1

[grady-young]

+1

[farzadsoltani]

+1

[king8fisher]

+1 hidden files could be shown with a different style, but still allowed to be picked.

[wtshek]

+1

[aaronjeong-supademo]

+1

[supatauqueer]

+1

[tylerseymour]

If anyone needs a workaround, which at least protects you from inadvertently committing secrets, you can:

• Create a secondary .gitignore-style file
• Add a pre-commit hook which rejects any files on that list from being committed

/.no-commit

.env
build

.git/hooks/pre-commit

#!/usr/bin/env bash
set -euo pipefail

RULEFILE=".no-commit"
[ -s "$RULEFILE" ] || exit 0

# Collect patterns (ignore blank/comment lines)
specs=()
while IFS= read -r line; do
  [[ -z "$line" || "$line" =~ ^[[:space:]]*# ]] && continue
  specs+=( "$line" )
done < "$RULEFILE"
[ ${#specs[@]} -eq 0 ] && exit 0

# Staged files (NUL-delimited to be safe)
staged=()
while IFS= read -r -d '' f; do
  staged+=( "$f" )
done < <(git diff --cached --name-only -z)

[ ${#staged[@]} -eq 0 ] && exit 0

bad=()

# Precompute the matched set once
matched="$(git ls-files -- "${specs[@]}")"
# Turn it into a fixed-string grep list
for f in "${staged[@]}"; do
  if printf '%s\n' "$matched" | grep -Fx -- "$f" >/dev/null; then
    bad+=( "$f" )
  fi
done

if [ ${#bad[@]} -gt 0 ]; then
  echo "Commit blocked by $RULEFILE:"
  printf '  %s\n' "${bad[@]}"
  exit 1
fi

Execution:

git:(master) ✗ git add .
git:(master) ✗ git status
On branch master
Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded.
  (use "git pull" to update your local branch)

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   .env
        new file:   build

git:(master) ✗ git commit -m "Updates"
Commit blocked by .no-commit:
  .env
  build

[hesreallyhim]

Some more workarounds off the dome before I ask Claude for the optimal solution:

• Maintain a .gitkeepme file or something (.gitkeep already kinda has a purpose) which is like a .gitignore list. Put the files you want to show claude but not commit into there, and leave them out of .gitignore. When you commit, add -A, then git reset on those files and keep (+ any steps to avoid pre-commit hooks from adding them). (I think this is like @tylerseymour is suggesting but, you know, for dumb people like me. 🤣)
• Maintain a safe branch with a full .gitignore. Do work off another trunk with a gitignore that omits the things you want claude to see. After each commit on the unsafe branch, do "merge --no-commit" onto the safe branch. Reset the .gitignore so that it never gets affected by the merge, then finish the commit. Risky but doable. *.gitkeepme thing again. this time, what you do is copy gitignore to gitignore_bak, and gitkeepme to .gitignore, do the commit, then swap the files back.

These are all a little risky, but i'm sure there's ways to make them safer. Or not, I'm spitballing but i think something like this workflow is viable, and would be safe using git hooks or claude hooks + extra guardrails if you want. 🤷

[arasakik]

+1

[pa1ar]

+1

[matthewdicataldo]

+1

[Tasemu]

+1

[Owenxz]

+++

[jmroon]

dotfiles and folders which are not gitignored are also restricted from indexing. For example, our team has a .vscode/settings.json and claude code cannot access it, even though it's in source control.