Claude Code can’t see project files: why and what to do in 2026

A familiar picture: you ask Claude Code to fix a file, and it replies that no such file exists. Or it silently changes something completely different from what you meant. You open the folder—the file is there, right where it should be. But Claude seems not to notice it.

Almost always, there’s one reason, and nothing is broken. Claude doesn’t see files on the entire computer. It can access only the folder from which you launched it. Launching inside a sibling folder or below the project root can put needed files outside the working tree. Launching from a parent such as home instead gives a broader scope; it does not make a descendant project inaccessible. I’ll explain step by step why this works the way it does and how to give Claude access to the files it needs. I’m quoting commands and settings directly from the official Claude Code documentation, which I checked in early September 2026.

Additional materials on configuring tools are available in the Ailoot documentation.

Why Can’t Claude Code See Some Project Files?#

By default, Claude Code works with one folder: the one where you entered the claude command and started the session. The documentation says this directly.

This folder is its working directory. Inside it, Claude reads any file without extra questions: editing a prompt, searching code, reading a specific file—it all works right away. But everything outside this folder is off-limits by default. A neighboring folder, a folder one level up, another drive—Claude won’t look there until you allow it.

That’s where a working-folder mismatch can matter. Say your project is /Users/you/my-shop, but you launched Claude from /Users/you/other-project, a sibling folder. The index.html in my-shop is outside that working tree. Launching from /Users/you is a different case: my-shop is a descendant and is not inaccessible merely because you started from home, though the selected context is broader than intended. Access to a folder also does not mean every file has already been read.

Next, I’ll walk through how to check and fix this: first we’ll confirm which folder Claude was launched from, then we’ll give it access to the files it needs in different ways—from a one-time instruction to a permanent setting.

How Can You Check Which Folder Claude Code Was Launched From?#

Before fixing anything, make sure the folder is really the issue. It’s easy to check. Ask Claude in the chat to show which directory it’s currently in—it will run pwd, which is safe: the command only displays the path and doesn’t touch anything.

pwd

The reply shows the actual working directory. Compare it with the full project path: /Users/you/other-project is a sibling of /Users/you/my-shop, while /Users/you is its parent. The sibling case puts my-shop outside the working tree; the parent case includes it but does not select that specific project as the root.

The cleanest way to resolve this mismatch is to launch Claude directly from the project folder. Close the current session, go to the right folder in the terminal, and launch Claude from there:

# Replace this illustrative path with your actual project root.
cd /Users/you/my-shop
claude

Now my-shop will be the working folder, and all the project files will be in view. The same rule applies in an editor such as VS Code: open the folder that contains the project. Not the folder one level above and not the entire drive. The folder you open determines what Claude considers its working directory.

If relaunching is inconvenient—for example, you’ve already given Claude context in this session and don’t want to lose it—you can add or switch folders on the fly. The next two sections cover that.

How Can You Show Claude Code a File in a Neighboring Folder?#

Sometimes a project isn’t kept in just one folder. The code is in one place, images or text in a neighboring folder, and shared components somewhere else nearby. Restarting Claude in each folder in turn is inconvenient. It’s better to give it access to the folder it needs while keeping the main folder as the working directory.

The simplest way is to do this directly in the active session with the command:

/add-dir ../assets

Enter /add-dir and the folder path, and Claude will immediately have access to its files on the same footing as files in the main folder. It won’t ask for permission again: the added folder follows the same rules as the working directory.

If you know in advance that you’ll be working with multiple folders, open access as soon as Claude starts—using the same path, but with a flag:

claude --add-dir ../assets

And when you need the same neighboring folder in a project all the time, there’s no need to add it manually every time. The settings.json settings file has an additionalDirectories key. List the paths there, and they’ll open automatically each time Claude starts:

{
  "permissions": {
    "additionalDirectories": ["../assets", "../shared"]
  }
}

One caveat for Windows: you can’t add a network folder using a path like \\server\shared—Claude doesn’t accept such paths. Mount it as a separate drive with a drive letter, then pass that letter using --add-dir. Ordinary local folders don’t have this issue.

What if adding a neighboring folder isn’t enough and you need to move to another folder entirely? There’s a separate command for that, covered below.

How Can You Switch Claude Code to Another Folder During a Session?#

Sometimes adding a neighboring folder isn’t enough—you need to change the main folder and move to another project without losing the context you’ve built up. Use the /cd command:

/cd ../another-project

Afterward, Claude treats the new folder as its working directory. You keep the entire conversation history, but the place Claude uses as its reference point for files changes to the new location. Claude also picks up the CLAUDE.md instruction file from the new folder, if one is there—that is, it adapts to the rules of the new project.

One thing to know about trust: if you haven’t worked in this folder before, Claude will ask whether you trust it when you move there. This is a safeguard: an instruction file in an unfamiliar folder could contain anything, so Claude first checks that it’s your project. Confirm, and then carry on.

The difference between the two commands is simple. /add-dir keeps the main folder as the working directory and opens a neighboring folder in addition to it—useful when parts of a project are scattered around. /cd moves the entire working directory to a new location—useful when switching to another project. The /cd command was introduced in version 2.1.169, so if it’s missing, update Claude Code. I have a separate guide on how to update Claude Code.

Claude Code seeing files is only the foundation. Stable results don’t come from file access alone. They come from what those files contain and how you build context around the project.

Why Can’t Claude Code See a File in a Subfolder?#

It’s important not to confuse two different situations here. A neighboring folder (one outside the project) is completely off-limits until you add it. A subfolder inside the project is different: Claude has access to it, but it doesn’t keep the folder’s contents in mind from the start.

Here’s how it works. When Claude starts, it loads what’s at the project’s top levels. It loads files from subfolders on demand, when it goes there to read something. The documentation describes this behavior for instruction files, and the same logic applies to context in general.

In plain language: the file in a deeply nested subfolder hasn’t disappeared and is fully accessible. Claude just hasn’t remembered it yet because it hasn’t looked there—which explains why it can feel as though Claude “can’t see” a file even though it’s there and accessible.

You can fix this in one line. Give Claude the file path directly—for example, src/components/header.jsx—or simply ask it to read the file first. As soon as it looks there, the file will enter the context, and you can work with it as usual. There’s no need to change any settings.

Where Do Files Disappear from the @ Menu, and What Does .gitignore Have to Do with It?#

Another common reason to think Claude has “lost” a file is the file picker. When you type @, a list pops up, making it convenient to select a file without typing its full path. But the list doesn’t show everything.

By default, the @ menu hides files listed in .gitignore. That file specifies what shouldn’t be added to the shared repository: service folders, files containing passwords and environment settings, and completed build output. The reasoning is clear—usually you don’t need to work with these files manually, so they would only clutter the list. But sometimes you do need one of those files, and it isn’t in the menu.

The respectGitignore setting controls this. It’s on by default, so files from .gitignore don’t appear in the menu. If you want to see them, switch it to false:

{
  "respectGitignore": false
}

You can do the same thing without editing the file, using the /config command inside Claude Code. The toggle there is called “Respect .gitignore in file picker.” Uncheck it, and the hidden files return to the menu.

One important caveat: respectGitignore applies only to the @ menu and has nothing to do with file access. Even when a file is hidden from the list, you can always enter its path manually, and Claude will read it. The menu is a convenience feature; it doesn’t set the access boundary.

What Should You Do If Claude Code Can’t Read a Specific File?#

If the folder is definitely right and access is open, but Claude still won’t read one particular file, it’s most likely restricted. Restrictions live in the settings.json settings file and come in two kinds.

The first is a targeted restriction on specific files. In the settings, these are deny rules, and they most commonly apply to the .env file, where keys and passwords are stored:

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

Such a rule blocks Claude from reading the specified files, and it’s intentional. Keys and passwords shouldn’t end up in a conversation with the model, so .env is locked down by default. If you see that Claude won’t read .env or a similar file containing secrets, that’s by design, and you shouldn’t remove this restriction without a compelling reason.

The second kind is a general restriction on everything outside the working folders. The blockReadsOutsideWorkingDirectories setting controls it. When enabled, Claude refuses to read any file outside the working directory, even if you try to open it directly. If it’s set to true and you need an external file, either add its folder using /add-dir or turn off the restriction:

{
  "permissions": {
    "blockReadsOutsideWorkingDirectories": false
  }
}

This setting was introduced in version 2.1.257. It’s worth checking both deny and blockReadsOutsideWorkingDirectories when you’ve tried everything else but the file is still off-limits.

Where Should You Start If Claude Code Can’t See Files?#

Here’s a short plan you can follow from top to bottom.

1. Check the working folder: ask Claude to show the current directory using pwd and compare it with the project’s location.
2. If the folders differ, relaunch Claude from the right one (cd project, then claude) or move there with the /cd command.
3. Need files from a neighboring folder? Add it with /add-dir or the --add-dir flag when launching Claude.
4. A file from a subfolder isn’t in context? Give Claude its path directly or ask it to read the file.
5. A file is missing from the @ menu? That’s .gitignore. Set respectGitignore to false or uncheck the box in /config.
6. One specific file is locked? Check the deny and blockReadsOutsideWorkingDirectories rules in settings.json.

In nine cases out of ten, the first step solves everything: Claude was launched from the wrong folder. File access is the foundation, but it won’t build your project for you. I’ve covered in detail how to build context around Claude so it keeps the whole project in mind and doesn’t lose the thread in my guide to the Second Brain in Claude Code.

Find additional materials on working with tools in the Ailoot documentation.