Desk Clarity

Everyday document & browser help

VS Code Ctrl+P misses ignored files: separate ignore rules from exclude settings

By ON Lab · Sources checked November 8, 2026

For filename results in VS Code Quick Open, inspect search.useIgnoreFiles and the applicable exclude patterns separately. Disabling ignore-file use can include files omitted by .gitignore or .ignore, but it does not automatically remove every files.exclude or search.exclude rule. A targeted exception can be preferable when you need only one otherwise excluded area.

A historical reader specifically asked about Ctrl+P file search, not searching text inside files. We checked current official editing and settings documentation, the stable release metadata for VS Code 1.145.2, and the corresponding released source for Quick Open's file query and ignore settings. This is documentation and source inspection; we did not run a native VS Code workspace or reproduce the reader's project.

Identify which search surface is missing the file

Quick Open looks for file names and paths. The Search view looks for content and has its own visible include/exclude inputs. Quick Search is another text-search interface. A setting or button described for one surface should not be treated as proof that every other search used the same request.

Use Ctrl+P on the relevant Windows or Linux setup, or the platform's Quick Open command such as Command-P on Mac, and enter the expected filename. Confirm the file is under the folder you actually opened as a workspace. A global desktop file search and a workspace query do not have the same scope.

Review the workspace's ignore-file policy

Open VS Code Settings in the intended scope and inspect Search: Use Ignore Files. The official settings schema describes it as controlling .gitignore and .ignore during file searches and gives it a true default. In an appropriate workspace setting, disabling it is expressed as:

{
  "search.useIgnoreFiles": false
}

This is a property to merge into the existing reviewed settings object, not an instruction to replace the whole file. Preserve unrelated settings. Save, reopen the same setting and confirm the effective value before testing Quick Open again.

Global Git ignore files and ignore files in parent folders have separate search settings. If either is explicitly enabled in your setup, review search.useGlobalIgnoreFiles and search.useParentIgnoreFiles as part of the intended policy. Do not promise that changing one boolean removes every possible exclusion or filesystem access limit.

The stable source we inspected connects Quick Open's workspace file queries to the normal query builder, which reads these settings per folder. That supports the documented setting relationship; it is not an executed test of every extension, remote provider or multi-root configuration.

Exclude globs remain a separate layer

Current VS Code help describes files.exclude and search.exclude patterns as another way to omit paths. Search inherits file exclusions, and the current documentation explicitly says exclude exceptions can also apply to file search in Quick Open.

If ignore-file use is disabled but the filename is still absent, inspect these patterns and their scope. In a multi-root workspace, verify the setting for the actual folder containing the file. A broader user preference and a folder-specific value can lead you to read one value while the query uses another.

Changing editor search settings does not change Git's tracked files or rewrite .gitignore. If the question is why Git itself ignores a file, use the separate Git ignore-rule source checks. Finding a filename in Quick Open does not prove Git would add it.

Use a narrow exception when that is the real need

The current editing help gives this example for searching a selected area inside the otherwise excluded node_modules folder:

{
  "search.exclude": {
    "!node_modules/@types": true
  }
}

Its documentation says those exceptions also apply to Quick Open file search and can override .gitignore rules. Review the exact pattern and the existing exclusion object before adding an exception. A root-relative path example is not automatically a pattern matching the same name at every depth.

This exception mechanism belongs to the settings, not to the Search view's files-to-exclude input. It can allow the intended search area while retaining other exclusions. We did not execute the example in a native workspace, so test the exact selected path and installed version before assuming it covers the desired files.

Do not confuse a Search-view toggle with Quick Open's proof

The Search view has a Use Exclude Settings and Ignore Files toggle. Official help says disabling it bypasses ignore files and exclusion settings for that search, while explicit include and exclude inputs still apply. It is useful when diagnosing that content-search request.

The reader's original question concerns filename Quick Open. Confirm that result directly after a setting change instead of treating a content-search hit as sufficient evidence. Likewise, a recent or already open file can affect what a quick picker displays; test a known file and record the exact query rather than inferring completeness from one familiar history entry.

Verify with a small known case

  1. Choose a non-sensitive known file under the opened workspace and record its relative path.
  2. Confirm whether an ignore file or an exclude setting actually matches it.
  3. Change the narrowest intended workspace setting or exception.
  4. Save and reopen the setting to confirm the full value.
  5. Run Quick Open with that filename and inspect the returned path.
  6. Check a file that should remain excluded and restore the prior value if the scope became too broad.

Opening generated or dependency trees to search can increase the result set and work performed. Choose a deliberate scope and verify it. This walkthrough does not certify that every file outside the workspace, behind a filesystem restriction or supplied by an extension will appear.

Checked November 8, 2026 against current Microsoft documentation and the source associated with stable VS Code 1.145.2. No native editor settings, extension behavior, remote workspace, performance test or original project was executed.

Sources