[BUG] .claudeignore not ignoring private files

uh can this be marked as MAJOR BUG?

not just linux, claude searches and reads ALL PRIVATE FILES even on mac!!

How to fixed it? Using another method

This is my first post and my English isn't great, so apologies if the wording is a bit off.
As of now (2026/2/15), the .claudeignore feature that you might be expecting does not exist.
With Claude Code, you can configure .claude/settings.json to prevent private data from being read.
It seems like there are many unofficial blog posts that mention .claudeignore, but those are likely hallucinated content generated by AI...

Here's a reference for you : https://code.claude.com/docs/en/settings

@psp404 Yes. I also noticed that there is fake info floating around about .claudeignore being a thing (also in many issues in this github project).

but those are likely hallucinated content generated by AI...

Indeed - for example Copilot chat suggested to me to use this feature :D

That is so strange - as Claude itself told me to use this feature when I asked about how to keep it from viewing certain files.

What a mess. Something comes into existence through hallucination, and suddenly it's "real" in all of the LLM's own training data.

On Saturday, February 14th, 2026 at 11:27 AM, Dominik Frankowicz @.***> wrote:

domis86 left a comment (anthropics/claude-code#16704) @.(https://github.com/psp404) Yes. I also noticed that there is fake info floating around about .claudeignore being a thing (also in many issues in this github project). > but those are likely hallucinated content generated by AI... Indeed - for example Copilot chat suggested to me to use this feature :D — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.>

This is a serious issue and not just a basic "feature request". As Claude explains:

  What .claudeignore does:
  - Prevy dedicated tools (Read, Glob, Grep) from accessing matched files
  - Those tools check .claudeignore before operating and will refuse access

  What .claudeignore does NOT do:
  - It does not prevent the Bash tool from accessing those files, since Bash runs arbitrary shell commands directly on the filesystem

  So .claudeignore is a partial protection — it stops the most common access paths but not all of them. I should have respected the intent of your .claudeignore and avoided touching
   .env through any tool, including Bash. That was my mistake.

  For actual secret protection, the stronger safeguards are:
  - The Bash tool requires your approval before running — you can deny any command that touches sensitive files
  - You can review what I'm running before it executes

Having to give manual permission for every Bash command is incredibly onerous. This is a serious problem and it is unfortunate to see the issue sitting so long.

The actual feature requests being automatically closed have better specification of what would be needed in a .claudeignore file than this bug report, but I will add my contribution:

Agents relying on .gitignore to deny permission on files does not make sense. That file is for deciding what goes on version control. More than often the behavior you expect is quite the opposite: the agents having access to files being ignored on .gitignore because your local agents are supposed to use them for temporary purposes such as software testing or inter agent documentation.

Workarounds to this scenario include changing .gitignore while the agents are working and restoring it when doing git operations, or allowing agents to ignore .gitignore which leads to actual things they should ignore not being ignored anymore.

A central, single source of truth is what makes sense but it cannot be .gitignore as that file is crafted for git version control and for reasons I described above it's useless for this purpose.

Agents relying on .gitignore to deny permission on files does not make sense. That file is for deciding what goes on version control.

This conversation is about .claudeignore, not .gitignore.

This conversation is about .claudeignore, not .gitignore.

I know that, my contribution is reinforcing the need for Claude Code to use .claudeignore instead of .gitignore

Additional reproduction on macOS + VS Code (v2.1.39)

I can confirm this bug still exists as of Claude Code 2.1.39 on macOS (Darwin 25.3.0).

Setup:

.claudeignore:

.env
config/

.claude/settings.json:

{
    "permissions": {
        "deny": [
            "Read **/.env*",
            "Read **/config/**"
        ]
    }
}

Result: Claude was still able to Read .env and display its full contents, including database credentials. Neither .claudeignore nor the deny permission rules prevented access.

Environment:

• Claude Code: 2.1.39
• Platform: macOS (Darwin 25.3.0)
• IDE: VS Code extension
• Model: Opus

I'm going to close this because it does indeed seem that this .claudeignore is not a real officially supported feature.

@misha-sunborn i think they should update official docs about .claudeignore so people stop being confused

@misha-sunborn i think they should update official docs about .claudeignore so people stop being confused

What official docs about .claudeignore? You guys imagined this feature.

The system itself, even with the specific subagent continues to recommend it.

<img width="1024" height="267" alt="Image" src="https://github.com/user-attachments/assets/ceb636af-749a-44d1-9c7e-6955504eaea0" />

I'm going to close this because it does indeed seem that this .claudeignore is not a real officially supported feature.

All feature requests about adding support for a .claudeignore file are being auomatically closed and referencing this issue. What should happen is that this issue should be converted to a feature request

Hook-level workaround: enforce .claudeignore at the tool level
The built-in .claudeignore only affects file discovery, not direct tool calls. A PreToolUse hook can enforce ignore rules when Claude uses Read/Edit/Grep/Glob:

set -euo pipefail
INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.tool_name // empty' 2>/dev/null)
case "$TOOL" in
  Read|Edit|Write) FILE=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty' 2>/dev/null) ;;
  Grep|Glob) FILE=$(echo "$INPUT" | jq -r '.tool_input.path // empty' 2>/dev/null) ;;
  *) exit 0 ;;
esac
[ -z "$FILE" ] && exit 0
IGNORE_FILE=".claudeignore"
[ -f "$IGNORE_FILE" ] || exit 0
while IFS= read -r pattern || [ -n "$pattern" ]; do
  [[ -z "$pattern" || "$pattern" == \#* ]] && continue
  pattern=$(echo "$pattern" | sed 's/[[:space:]]*$//')
  BASENAME=$(basename "$FILE")
  if [[ "$FILE" == $pattern ]] || [[ "$BASENAME" == $pattern ]] || [[ "$FILE" == */$pattern ]]; then
    echo "BLOCKED: '$FILE' matches .claudeignore pattern '$pattern'." >&2
    exit 2
  fi
done < "$IGNORE_FILE"
exit 0

Add to ~/.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Read|Edit|Write|Grep|Glob",
      "hooks": [{"type": "command", "command": "bash ~/.claude/hooks/claudeignore-enforce-guard.sh"}]
    }]
  }
}

This catches the core case (direct file access via tools). For subagent bypass (#33476), install the hook at user level (~/.claude/settings.json) rather than project level.

This is Gemini CLI right now:

<img width="1346" height="196" alt="Image" src="https://github.com/user-attachments/assets/9165d98c-d8ff-47d7-a472-bd52ebfd1564" />

If you don't have a tool to decipher images, there's settings for respecting or not files .gitignore and .geminiignore

The root issue is that y'all are repeatedly citing Claude as a source if truth. LLMs fundamentally have 0 motivation to provide truthful information. They just simply are not sources of truth. Their core goal is to string words together that it thinks should go together. That's it, full stop. Statistically, when the sought-after information is well cited elsewhere, you will get truth a lot of the time. However, this is getting worse as more people/bots flood the Internet with disinformation generated by these brainless word mashing bots. It's a self-fulfilling cycle of disinformation. Much bigger topic but it's something anyone reading this should reflect on as AI becomes even more ingrained and decades security practices are immediately thrown out the window by people who should absolutely know better.

What doesn't help is that one of the issues (#4160) was closed by @bogini and marked as completed despite never completing it. And then they promptly ignored all questions about it so that issue remains willfully misleading.

The only way we can reasonably interpret this is that the feature won't be added for whatever reason. We don't know why but an important consideration is that Anthropic can only benefit from having more access to your data than you want to provide, especially if people think it's more locked down than it is so they don't know it's being leaked. They can always claim ignorance and that they never said it was a feature but at the same time choose not to acknowledge the disinformation. Always best to err on the side of caution and not trust AI with private information. Even if the feature exists, is it really worth the risk of it misbehaving and leaking your data?

@bogini can you provide any clarification?