# Wildcards

<figure><img src="https://762006384-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MJXOXEifAmpyvNVL1to%2Fuploads%2FMfL4YdvQcYit0GLCTk9l%2FReference%20-%20Wildcards.png?alt=media&#x26;token=628562bb-40e7-4ade-8aa0-0e08ffc40cae" 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](https://docs.keeper.io/en/keeperpam/endpoint-privilege-manager/reference/broken-reference) 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

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.

***

### 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.
