Context Filters

Context filters are an admin-defined exclusion list for 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 works

Filtering happens before any content reaches the LLM. There is no instruction in the prompt for the model to reason its way around.

Excluded content is also indistinguishable from content that was never there. It is simply absent, and a read of filtered content returns the same not-found error as a read of something 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 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 only. No backreferences and no lookaround — a pattern like (a)\1 is rejected.
• Multiple patterns in one list are OR'd. ["^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 AND'd, and an omitted field means "match anything".

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 github.com/acme/frontend stay visible, and the rest of backend, src/main.go, its refs, its commit history, is untouched.

Rules never narrow one another. Each is evaluated on its own, and any match hides the content. In the configuration example above, .env files are hidden everywhere and deploy/ is hidden in backend. The repository-scoped rule does not limit the reach of the instance-wide one.

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 contains none of it. If you @-mention filtered content, Deep Search reports it as not found rather than acknowledging that it was excluded.