macOS - Software Lifecycle - Manage Third Party Override Options

What the third-party patching override Worklet does

This Automox Worklet™ writes a local override file on macOS endpoints that tells the Automox agent which third-party applications it is allowed to force-close before patching. The default Automox behavior is conservative: if an application is designated as "App will NOT patch when running," the agent will not patch it while the user has it open. That default protects unsaved work, but it also means long-lived sessions (Chrome tabs, Slack, Microsoft Teams, Skype) never reach a patch window and the CVE backlog on those bundles grows.

The Worklet reads a bundle-name allowlist from the policy variable kill_if_running_titles, deduplicates the entries with awk, and writes them into /Library/Application Support/Automox/.tools/ax_overrides in the comma-separated format the agent expects (for example, com.google.Chrome,1 on its own line). The evaluation phase stages the candidate file as ax_overrides.new alongside the live override and runs diff -q between the two. If the files match, the endpoint is compliant and no remediation runs. If they differ, the endpoint is flagged and remediation moves the .new file into place.

Because the evaluation phase is idempotent, the override stays pinned across every Automox scan. If an admin manually deletes /Library/Application Support/Automox/.tools/ax_overrides or a build script overwrites it during reimaging, the next diff -q comparison returns a mismatch and the remediation pass moves ax_overrides.new into place. To remove the override entirely, clear the kill_if_running_titles array; the next remediation empties the file and Automox reverts to default per-application patching behavior.

Why pin third-party patching behavior at fleet scale

Browser and collaboration clients are the largest unpatched CVE surface on a typical Mac fleet, and they share the same operational pattern: users keep them open for weeks. Chrome (com.google.Chrome), Microsoft Teams (com.microsoft.teams2), Slack (com.tinyspeck.slackmacgap), and Skype (com.skype.skype) are all on the Automox "App will NOT patch when running" list, which means the default policy quietly skips them on every patch run. The override file is the documented escape hatch: it tells the agent which bundles are safe to terminate on this fleet because the security team has decided patch latency is the larger risk.

The override file is also easy to lose. Reimaging a Mac wipes /Library/Application Support/Automox/.tools/ unless the deployment workflow restores it, an agent reinstall recreates the directory empty, and an admin troubleshooting a stuck patch can blank the file by hand and forget to restore it. The Worklet treats kill_if_running_titles in the policy as the source of truth, regenerates ax_overrides.new on every evaluation, and only writes when diff -q surfaces a mismatch, so the override is rebuilt automatically after a wipe instead of becoming a quiet audit finding on browser patch latency.

How third-party override enforcement works

1. Evaluation phase: The Worklet sources the kill_if_running_titles bash array from the policy. It calls create_override_file, which touches /Library/Application Support/Automox/.tools/ax_overrides if the file is missing and removes any leftover ax_overrides.new artifact. It then writes each bundle name as <bundle>,1 into ax_overrides.new using a printf-into-awk pipeline that drops duplicate bundle entries. The evaluation runs diff -q against the live override file: if the files match, the script prints the current bundle list (with the ,1 suffix stripped via sed) and exits 0. If they differ, the script exits 1, which flags the endpoint for remediation. If the array is empty, the script exits 0 with no changes.

2. Remediation phase: The remediation script installs a bash trap that cleans up ax_overrides.new on exit. It first checks that the live override file exists; if not, it errors out because the evaluation phase must run first to stage the new file. If ax_overrides.new is missing on a re-run, the script blanks the live override file and exits 0, which reverts the fleet to default Automox patching behavior. Otherwise it runs diff -q one more time, and if the files differ it executes mv "${overrideFile}.new" "$overrideFile" to swap the new override into place. The final state is logged with sed 's/,1//g' so the activity log shows exactly which bundles will be force-closed on the next patch run.

Third-party override requirements

• macOS endpoint enrolled in Automox with agent version 1.42.22 or later (the override file format is only honored by 1.42.22+)

• Root context for the Automox agent so it can write to /Library/Application Support/Automox/.tools/ (the default agent context already meets this)

• Bundle names supplied in kill_if_running_titles must match the Automox Third-Party Naming Standards exactly; the strings are case-sensitive and the leading com. prefix is required (com.google.Chrome, com.microsoft.teams2, com.tinyspeck.slackmacgap, com.skype.skype, com.adobe.Reader)

• The override only applies to applications Automox has classified as "App will NOT patch when running"; adding a bundle that already patches silently has no effect

• End user communication recommended: force-close drops unsaved work in the targeted apps, so pair the policy with a notification Worklet or schedule it outside business hours

• Policy variable kill_if_running_titles configured as a list of bundle names; leaving it empty causes the evaluation to exit 0 without writing the override file

Expected state after third-party override enforcement

On a compliant endpoint, /Library/Application Support/Automox/.tools/ax_overrides exists and contains one <bundle>,1 line per allowlisted application. Subsequent Automox scans report the endpoint as compliant without invoking remediation, because the evaluation diff returns no changes. The next time the Automox agent runs a third-party patch job that targets one of the listed bundles, it terminates the running process before applying the patch, instead of skipping the endpoint. Patches that previously sat in pending for weeks because Chrome or Slack was always running now close within a single patch cycle.

Validate by reading the file directly with sudo cat "/Library/Application Support/Automox/.tools/ax_overrides" and confirming each expected bundle appears exactly once. Cross-check the Automox activity log for the remediation run: the script prints the bundle list (with the ,1 suffix stripped) on success, so the audit trail names every application affected. To revert the override on a single endpoint without changing the policy, blank the file with sudo : > "/Library/Application Support/Automox/.tools/ax_overrides"; the next evaluation will rewrite it. To revert against every endpoint in scope, clear the kill_if_running_titles array in the policy and let the next remediation cycle empty the file.