Manage Third-Party Override Options Worklet — "No Overrides File Found" and Apps That Still Skip Patching

Brendan

Updated: July 24, 2026 01:46

Issue

An administrator deploys the prebuilt Manage Third Party Override Options worklet from the Worklet Catalog, but third-party applications still do not update. Common forms of this issue:

The Activity Log for the worklet shows "No overrides file found. Exiting." (older policy copies) or "No new overrides file found. No action required. Exiting" (current copies), and it is unclear whether this is an error or means the listed software is not installed.
Applications that must be closed before patching (for example Notepad++, Node.js, Zoom) continue to fail with a message such as "<application> is unable to patch because it is currently running" even though the application was added to the worklet's $killIfRunningTRUE list.
The worklet was expected to patch the applications itself, and nothing appears to update after it runs.

In most cases the worklet is working as designed and the actual problem is one of three things: the worklet was expected to do the patching, the application names entered do not exactly match the required package names, or the log message was misread as a failure.

Environment

Automox (current agent release)
Windows worklet: Windows - Software Lifecycle - Manage Third Party Override Options
macOS worklet: MacOS - Software Lifecycle - Manage Third Party Override Options
Automox console: Worklet Catalog, Policies, Activity Log

Overview

The worklet does not install or patch anything. It only writes a small local overrides file to the device (Windows: C:\Program Files (x86)\Automox\ax_overrides; macOS: /Library/Application Support/Automox/.tools/ax_overrides). A separate third-party patch policy does the patching, and it reads this file at its next run to decide, per application, whether to force-close the application first (kill_if_running) or, on newer Windows copies, whether to uninstall the previous version first (uninstall_before_patch). If no patch policy targets the application, adding it to the worklet changes nothing.

Like every worklet, it has two parts. The evaluation code runs at every device scan: it builds a new staging copy of the overrides file from the arrays and compares it to the file already on the device. The remediation code runs at the policy's scheduled time or on a manual run: it copies the staging file into place. A manual Run on this device skips evaluation and runs remediation directly, which is why manual runs often produce the "No overrides file found" / "No new overrides file found" message — remediation ran, found no newly staged file (either evaluation has not run on that device yet, or the file already matches the configured list), and correctly did nothing.

Two behaviors cause most confusion:

Entries are written to the file exactly as typed, with no validation. The worklet does not check names against installed software or the supported-title list. A misspelled or wrong-format name is written to the file but never matches anything at patch time, so the default behavior silently remains in effect — there is no error anywhere.
The name matching is exact and case-sensitive, and it matches on the internal package name, not the friendly name shown for the application.

Resolution

Confirm a third-party patch policy targets the affected applications and devices. The worklet only modifies how that policy patches; it does not patch on its own.
In the worklet's evaluation code, enter each application using its Cached Package Name exactly as listed in Naming Scheme for Third-Party Software Packages — for example NotepadPlusPlus (not Notepad++), NodeJS_LTS (not Node.js LTS), Cloudflare_WARP, google_chrome. Copy and paste the value; matching is exact and case-sensitive. If a title has multiple Cached Package Names (for example separate 32-bit and 64-bit packages), add a separate entry for each. On the macOS worklet, use the application's Bundle Name instead (for example com.google.Chrome), also case-sensitive.
Place each name in the correct array. Use $killIfRunningTRUE for applications designated "App will NOT patch when running" in Third Party Patching Best Practices that should be force-closed so they can patch. Use $killIfRunningFALSE for applications designated "App is shut down by Automox in order to patch" that should not be force-closed. Entries for titles that do not support the option are ignored.
Assign the worklet to the same devices the patch policy targets and run it. It only needs to complete once per device, and again after any change to the arrays — a recurring schedule is not required. Verify in the Activity Log that each target device reports "New override file found. Replacing existing file."

Interpret the Activity Log messages:

Message	Stage	Meaning
"No previous overrides file exists, remediation required"	Evaluation	First run on this device; the file will be created when remediation runs. Expected, not an error.
"Old file and new file do not match, remediation required"	Evaluation	The configured list changed; remediation will update the file.
"New override file found. Replacing existing file."	Remediation	Success — the overrides file is now in place.
"No overrides file found. Exiting." (older copies) or "No new overrides file found. No action required. Exiting"	Remediation	Remediation ran without a newly staged file: the device's overrides file already matches the configured list, or evaluation has not run on that device yet (common when the worklet is run manually right after assignment, because manual runs skip evaluation). It does not mean the software is not installed.
"Error creating new overrides file, check inputs."	Evaluation	The arrays produced no file — they are empty or malformed. Fix the array syntax; keep at least one entry present.

Wait for (or run) the patch policy. The override takes effect at that policy's next run — success in the worklet's own log only confirms the file was delivered.
If gated applications still fail with "unable to patch because it is currently running" after this, re-check step 2 first — a name that is not an exact Cached Package Name match fails silently. Then confirm the "New override file found" success message appeared on every affected device, not only a subset. For broader failures, see Troubleshooting Third-Party Application Patch Failures.

Notes

The "No overrides file found" message never indicates whether software is installed. Override entries for applications not present on a device are simply ignored at patch time.
Policies created from the Worklet Catalog keep a copy of the script from the moment they were created, so older policies may show the older message wording ("No overrides file found. Exiting.") while newer copies show the current wording. The meaning is the same.
To revert an override for one application, remove its entry from the array and let the worklet run again (next scan plus remediation); the title returns to Automox default behavior. Do not empty the arrays completely — with no entries at all, evaluation reports "Error creating new overrides file, check inputs." and the existing overrides file on the device is left unchanged. Keep at least one entry (a placeholder such as the shipped ExampleProductName is fine, since non-matching names have no effect).
To verify what a device actually received, view the overrides file directly at the path in the Overview; each line has the form Name.kill_if_running=True.
An alternative for a single application that must be closed by the end user at a convenient time is a targeted Patch Only policy with a notification — see Policy for Third-Party Apps with a Shutdown Requirement.
For the evaluation-runs-on-every-scan and manual-run behavior referenced above, see What happens when a policy is manually run?.
Automox University offers a guided course on this worklet, Managing Third-Party Overrides, covering configuration for both Windows and macOS.

Was this article helpful?

0 out of 0 found this helpful