# Policy: Wildcards

<figure><img src="/files/PZ24PDXtmzCpuNZALRTd" alt=""><figcaption></figcaption></figure>

**Audience:** IT admins. Use this when writing policy filters that match many applications or paths without listing each one.

## Overview

**Wildcards** let one pattern match many names or paths. Support depends on **where** you use them: application filters support wildcards in paths; folder filters use **prefix matching** only (no `*` in the folder path).

* **Application filters:** `*` matches any characters (regex-style `.*`). Path variables are resolved first, then the pattern is matched. Windows is case-insensitive; Linux/macOS are case-sensitive.
* **Folder filters:** The folder value is resolved (including variables) and then **prefix matching** is used: “does the full path **start with** this folder?” Wildcards in the folder path are **not** supported (e.g. `{downloads}\*` is treated as a literal `*`).

## Application Filter Wildcards

**Supported:**

* **Wildcards in paths:** e.g. `{programfiles}\*\*.exe` — matches any `.exe` in any subfolder of Program Files.
* **Path variables:** e.g. `{userprofile}\Documents\*.exe`, `{downloads}\*.pdf`.
* **Combined:** e.g. `{userprofile}\*\*.exe` — any `.exe` in any subfolder of the user profile.

**How it works:** `*` in the path is treated as “any characters.” The path is normalized, variables are resolved, then the pattern is matched. On Windows matching is case-insensitive; on Linux/macOS it is case-sensitive.

**Examples:**

* `*.exe` — any file ending in `.exe` (in the context where the pattern is applied).
* `{desktop}\*.exe` — any `.exe` on the user’s desktop (variable resolved per user).
* `{programfiles}\*\*.exe` — any `.exe` in any subfolder of Program Files.

## Combined Variable + Wildcard Examples

You can **combine** path variables with one or more `*` segments so a single pattern matches many paths (e.g. different app versions or install locations). Variables are resolved first, then each `*` matches any characters in that path segment.

| Pattern                                                                     | What it matches                                                                                                         |
| --------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| `{userprofile}\AppData\Local\GitHubDesktop\*\resources\app\git\cmd\git.exe` | Git bundled with GitHub Desktop, for any version folder (e.g. `app-3.2.1`, `app-3.3.0`) under the user’s Local AppData. |
| `{localappdata}\*\*\*.exe`                                                  | Any `.exe` three levels deep under the user’s Local AppData (covers per-app and versioned folders).                     |
| `{programfiles}\*\*\*.exe`                                                  | Any `.exe` in any subfolder of Program Files (e.g. `C:\Program Files\Vendor\Product\bin\app.exe`).                      |
| `{userprofile}\Documents\*\*.pdf`                                           | Any PDF in any one-level subfolder of the user’s Documents.                                                             |
| `{appdata}\*\*.exe`                                                         | Any `.exe` in any one-level subfolder of the user’s Roaming AppData.                                                    |

**Why combine:** Install paths often include version or build folders (e.g. `GitHubDesktop\app-3.2.1\...`). Using `*` in that segment lets one policy match all versions without updating the rule when the app is updated. See [Reference: Variables](broken://pages/E3BQ3kP4uECttGaKgOlA) for the full list of variables you can use in these patterns.

## Folder Filter (Extension.Folders) — Prefix Matching Only

When a policy uses **Extension.Folders** (or a folder-style filter), the product uses **prefix matching**:

* The folder value can use **path variables** (e.g. `{downloads}`, `{userprofile}`).
* The **full path** of the file being evaluated is checked: does it **start with** the resolved folder path?
* If yes, the folder filter matches (including all files in subfolders).
* **Wildcards in the folder path are not supported.** For example, `{downloads}\*` does **not** mean “any subfolder of Downloads”; the `*` is treated as a literal character.

#### **Examples:**

* Folder `{downloads}` → matches `C:\Users\Jane\Downloads\file.exe` and `C:\Users\Jane\Downloads\subdir\file.exe`.
* Folder `{userprofile}` → matches any file under the user’s profile.
* Folder `{downloads}\*` → **wrong**; use `{downloads}` if you want “everything in Downloads and subfolders.”

## Combining ApplicationCheck and Extension.Folders

{% hint style="info" %}

#### macOS Protected Paths and Wildcard Scope

Learn about [macOS Protected Path Design Intent](/keeperpam/endpoint-privilege-manager/reference/macos-protected-path-design-intent.md) in our [Reference](/keeperpam/endpoint-privilege-manager/reference.md) section.
{% endhint %}

When **ApplicationCheck** contains only a **filename pattern** (e.g. `*.exe`) and **Extension.Folders** is set, the product can combine them during preprocessing:

* Result: full path patterns like `{desktop}\*.exe` or `{downloads}\*.pdf`.
* Those are then evaluated with normal application/path matching (including wildcards in the path).

So you can write “all executables on the desktop” as: ApplicationCheck with `*.exe` (or similar) and Extension.Folders with `{desktop}`. No need to list every path by hand.

## Linux/macOS: Executables without Extensions

On Linux and macOS, many executables have no extension. You can:

* Use a pattern that matches “any file” in a folder (e.g. `*` with Extension.Folders), or
* List common extensions (e.g. `.sh`, `.bin`, `.run` on Linux; `.app`, `.command` on macOS) in ApplicationCheck and combine with Extension.Folders.

Folder filters still use prefix matching only; application patterns support `*` in the path.

{% hint style="info" %}

#### macOS Protected Paths and Wildcard Scope

Learn about [macOS Protected Path Design Intent](/keeperpam/endpoint-privilege-manager/reference/macos-protected-path-design-intent.md) in our [Reference](/keeperpam/endpoint-privilege-manager/reference.md) section.
{% endhint %}

## What to Avoid

* **Folder path with `*`:** e.g. `Extension.Folders: ["{downloads}\\*"]` — the `*` is literal; use `{downloads}` for “all of Downloads.”
* **Expecting wildcards inside folder strings:** Only prefix matching is applied to the resolved folder path.
* **Case on Linux/macOS:** Patterns are case-sensitive; use the correct case for paths and extensions.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.keeper.io/keeperpam/endpoint-privilege-manager/policies/wildcards.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.