Wildcards

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

---

Wildcards

Wildcards let one pattern match many names or paths. How they behave depends on the filter type — that distinction matters more than which policy type you're configuring.

Application Filters

Application Filters support wildcards in paths. * matches any characters (regex-style .*), path variables are resolved first, and then the pattern is matched. Matching is case-insensitive on Windows and case-sensitive on Linux/macOS. Application filters appear in every policy type that targets an executable — Privilege Elevation, File Access, Command Line, Least Privilege, the Agentic AI policy family (Agentic AI, Agentic Access, Agentic Privilege Elevation), and Custom — so a pattern like {programfiles}\*\*.exe works the same way across all of them.

Folder Filters

Folder Filters (the Extension.Folders field used primarily by File Access policies) support path variables but use prefix matching only: the folder value is resolved and then evaluated as "does the full path start with this folder?" Wildcards in the folder path are not supported — {downloads}\* is treated as a literal *. Because matching is prefix-based, a folder filter automatically covers that folder and all of its subfolders without any wildcard.

Command-Line ArgumentFilters

Command-line argument filters (used by Command Line policies and by Privilege Elevation policies with command-line scoping) support wildcards in command and argument patterns.

One Important Caveat

For File Access DENY policies with wildcards on Windows, executables in protected paths — {systemroot}, {system32}, {programfiles}, {programfilesx86} — are automatically excluded from matching so a broad wildcard can't accidentally block critical OS binaries. This exclusion is enforced at evaluation time and applies only to wildcard denies; explicit-path denies still match normally.

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

macOS Protected Paths and Wildcard Scope

Learn about macOS Protected Path Design Intent in our Reference section.

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.

macOS Protected Paths and Wildcard Scope

Learn about macOS Protected Path Design Intent in our Reference section.

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.