# Deep Search Context Filters

<TierCallout>
	Supported on [Enterprise](/pricing/plans/enterprise) plans. Configuring
	context filters requires site-admin access.
</TierCallout>

Context filters are an admin-defined exclusion list for [Deep Search](/deep-search). Anything matched by a filter is invisible to the agent: it never appears in an answer, and it cannot be read, searched, diffed, or resolved by any Deep Search tool.

## Why use context filters

- **Keep secrets out of the agent's context.** Excluded content never leaves your instance, so it cannot be quoted, summarized, or forwarded to a third-party model provider.
- **Reduce noise.** Vendored dependencies, generated code, and archived repositories can be hidden so Deep Search spends its research on code that matters.

## How context filters work

Filtering happens before any content reaches the LLM and does not rely on prompting, so the model cannot reason it's way around the filters. 

To Deep Search, excluded content is indistinguishable from content that does not exist. 

## Configuring context filters

A site admin configures filters under **Admin → Configuration → Advanced configuration**, inside the `experimentalFeatures` block of the site configuration. Each entry in `exclude` is an independent rule, and content is hidden if it matches any rule.

```jsonc
"experimentalFeatures": {
  "deepSearch.contextFilters": {
    "exclude": [
      // Hide an entire repository.
      { "repoNamePatterns": ["^github\\.com/acme/secrets$"] },
      // Hide secret-bearing files in every repository.
      { "filePathPatterns": ["\\.env$", "\\.pem$"] },
      // Hide deployment config in certain repositories only.
      {
        "repoNamePatterns": ["^github\\.com/acme/backend$", "^github\\.com/acme/frontend$"],
        "filePathPatterns": ["^deploy/", "^config/prod/"]
      }
    ]
  }
}
```

Config changes apply to the next Deep Search run; no restart is required. A rule must set at least one of the two fields.

## Pattern syntax

Both `repoNamePatterns` and `filePathPatterns` take a list of Go [RE2](https://github.com/google/re2/wiki/Syntax) regular expressions.

- **Patterns are unanchored.** `internal` matches `github.com/acme/internal-tools`. Use `^...$` when you mean the whole string.
- **`.` matches any character except a newline, including `/`.** Escape it as `github\.com`. The pattern `a.b` also matches the repository `a/b`.
- **Backslashes must be doubled in JSON.** The regex `\.env$` is written `"\\.env$"`.
- **Repository names and file paths match case-insensitively.** `README` also excludes `readme`.
- **RE2 does not support backreferences or lookaround assertions.** Patterns like `(a)\1` is rejected.
- **Patterns in a list are combined with OR** `["^a$", "^b$"]` matches either.

### What the patterns are matched against

`repoNamePatterns` is matched against the full repository name, including the code host: `github.com/acme/backend`.

`filePathPatterns` is matched against the repository-root-relative path, with no leading slash: `internal/auth/token.go`. Directories are matched with a trailing slash, so write directory rules as `^deploy/` rather than `^deploy$`. The trailing-slash form hides both the files inside `deploy/` and the `deploy/` entry itself in a parent listing.

## Combining repoNamePatterns and filePathPatterns

Within a single rule the two fields are combined with AND, and an omitted field means "match anything".

| Rule                    | What it hides                                        |
| ----------------------- | ---------------------------------------------------- |
| `repoNamePatterns` only | The whole repository                                 |
| `filePathPatterns` only | Matching paths in **every** repository               |
| Both fields             | Matching paths **only** inside matching repositories |

### Repository only

```jsonc
{"repoNamePatterns": ["^github\\.com/acme/secrets$"]}
```

`github.com/acme/secrets` disappears completely: it is dropped from repository lists and search results, its refs and revisions cannot be resolved, and every tool reports it as nonexistent.

Anchoring matters here. `^github\.com/acme/secrets$` leaves `github.com/acme/secrets-docs` visible, while the unanchored `acme/secrets` hides both.

### Files only

```jsonc
{"filePathPatterns": ["\\.env$", "^secrets/"]}
```

Every `.env` file, and everything under a top-level `secrets/` directory, is hidden in all repositories. The repositories themselves stay searchable, only the matching files go missing. A files-only rule never hides a repository, so `github.com/acme/backend` still appears in repository lists even if all of its files are filtered.

### Files within a repository

```jsonc
{
	"repoNamePatterns": ["^github\\.com/acme/backend$"],
	"filePathPatterns": ["^deploy/", "^config/prod/"]
}
```

`deploy/` and `config/prod/` are hidden in `github.com/acme/backend` only. The same paths in a different repo (e.g., `github.com/acme/frontend`) stay visible.

## Verifying a filter

Ask Deep Search a question that would require the excluded content, and @-mention the repository or file directly. A working filter produces an answer that does not reference the content, and the [list of sources](/deep-search) contains none of it. If you @-mention filtered content, Deep Search reports it as not found rather than acknowledging that it was excluded.