Wildcards

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

Return to Reference Index