macOS - Software Lifecycle- Remove Automox Remote Control Application

What the macOS Remote Control remover does

This Automox Worklet™ removes the Automox Remote Control module from macOS endpoints in a single policy run. The Worklet inspects every location the module touches – /Library/Application Support/Automox/modules/remotecontrol/, /Applications/Automox Remote Control.app, /Library/LaunchDaemons/com.automox.remotecontrold.plist, and /usr/local/var/log/remotecontrold.log – then unwinds the install in order: stop processes, bootout launchd services, run the bundled uninstaller, delete files, clean the temp directory.

The Worklet is careful about its blast radius. It targets only processes whose command path contains /Automox/modules/remotecontrol/, so a Cloudflare WARP tunnel running cloudflared elsewhere on the endpoint is left alone. The evaluation script returns exit code 2 when any Remote Control component is detected and exit code 0 when the endpoint is already clean, so a recurring policy reports compliance without re-running remediation on endpoints that never had the module installed.

Bundled VNC helpers come off the endpoint too. The remediation script removes TightVNC Viewer.app, TightVNC Server.app, OSXvnc.app, Vine Server.app, and their pkgutil receipts, then drops the matching launch agents and daemons under /Library/LaunchAgents/ and /Library/LaunchDaemons/. The final state is documented in /Library/Application Support/Automox/Logs/RemoveRemoteControl.log when AX_ENABLE_AGENT_SCRIPT_LOGGING is set.

Why retire Remote Control across the Mac fleet

Remote access tooling that no longer has a business owner becomes an audit problem fast. Security reviewers flag launchd daemons that can attach a screen-sharing session to a corporate Mac, especially when the binaries have stopped receiving updates. Leaving the Automox Remote Control module installed on endpoints that have moved to a different remote support tool – Splashtop, Jamf Remote, ScreenConnect, or a built-in like macOS Screen Sharing – creates a parallel access path the IT team is no longer monitoring. Deleting the module closes that path and removes the bundled VNC binaries that ship inside the install directory.

Applying the uninstall through an Automox policy scales the cleanup from a one-laptop terminal session to a Mac estate-wide evaluation in a single policy run. The evaluation phase checks for the remotecontrold process, the supporting launch daemons, and the bundled VNC helper apps; remediation only fires on the Macs that still have the module installed. Endpoints that already moved to a different remote support tool report as compliant on the first pass, so the policy converges on a clean state without an SSH-and-sudo loop, without an MDM script to chase, and without a manual verification step per endpoint.

How macOS Remote Control removal works

1. Evaluation phase: The script scans every Remote Control surface on the endpoint. It runs pgrep -f against remotecontrold, cloudflared, dialog, and osxvnc, then filters matches by command path so only processes inside /Automox/modules/remotecontrol/ are flagged. It checks files in that module directory (remotecontrold, cloudflared-darwin-amd64/arm64, dialog, osxvnc, config.json, rc-module.log, rc-stdout.log, rc-stderr.log), the temp subdirectory, /Applications/Automox Remote Control.app, /Library/LaunchDaemons/com.automox.remotecontrold.plist, /Library/LaunchDaemons/com.automox.remotecontrol.plist, /usr/local/var/log/remotecontrold.log, the com.automox.remotecontrold and com.tightvnc.server launchd labels via launchctl list, and pkgutil --pkgs for tightvnc or osxvnc receipts. Exit 2 means components found and remediation is scheduled; exit 0 means the endpoint is already clean.

2. Remediation phase: The script kills only the Remote Control instances of remotecontrold, cloudflared, and dialog (path-filtered against /Automox/modules/remotecontrol/), then runs launchctl bootout system /Library/LaunchDaemons/com.automox.remotecontrold.plist and launchctl remove for the com.automox.remotecontrol and com.tightvnc.server labels. If /Library/Application Support/Automox/modules/remotecontrol/remotecontrold is still executable, it runs ./remotecontrold uninstall --conf=config.json to let the module clean up its own state. The TightVNC and OSXvnc routines forget any pkgutil receipts, delete the .app bundles in /Applications/, remove /Library/Application Support/TightVNC and /Library/Application Support/OSXvnc, and clear the matching launch agents and daemons. The script then deletes every file under the module directory, removes the /Applications/Automox Remote Control.app bundle, deletes /usr/local/var/log/remotecontrold.log, drops the config.json, and clears the temp directory. The final response is a JSON payload (event_type RemoveRemoteControlMac) with per-component success flags and total duration, and the script exits 0 when overall_success is true.

Remote Control removal requirements

• macOS endpoint running Monterey, Ventura, Sonoma, or Sequoia (Intel or Apple Silicon; the script auto-detects amd64 vs arm64 cloudflared binaries via uname -m)

• Automox agent running as root, which is the default service context and is required for launchctl bootout system, pkgutil --forget, and writes under /Library/LaunchDaemons/

• Schedule outside active remote support windows; any in-flight Remote Control or VNC session is terminated when the daemon is killed

• Optional: set AX_ENABLE_AGENT_SCRIPT_LOGGING=true on the agent to write /Library/Application Support/Automox/Logs/RemoveRemoteControl.log for line-level audit evidence

• No additional parameters – the policy reads no Worklet variables, so the same Worklet runs unchanged across every Mac in the fleet

Expected state after Remote Control removal

After a successful run, /Library/Application Support/Automox/modules/remotecontrol/ contains no executables, the temp subdirectory is gone, /Applications/Automox Remote Control.app is deleted, /usr/local/var/log/remotecontrold.log is removed, and launchctl list returns no matches for com.automox.remotecontrold, com.automox.remotecontrol, or com.tightvnc.server. The bundled VNC artifacts also clear: /Applications/TightVNC Viewer.app, /Applications/TightVNC Server.app, /Applications/OSXvnc.app, /Applications/Vine Server.app, and /Library/Preferences/com.tightvncserver.plist no longer exist, and pkgutil --pkgs | grep -i "tightvnc\|osxvnc" returns nothing.

Validate by re-running the evaluation script; it should exit 0 with the message "No Remote Control components found." For a manual spot-check, run ls "/Library/Application Support/Automox/modules/remotecontrol/" (expected: No such file or directory), launchctl list | grep -i remotecontrol (expected: empty), and ps -ax | grep -i "remotecontrold\|osxvnc" (expected: only the grep itself). The JSON response payload also surfaces in Automox activity logs with the per-component success flags; in particular, rcm_uninstall_success, service_removed, files_removed, config_removed, and overall_success should all read true. Subsequent attempts to start a Remote Control session against the endpoint fail because the daemon and its launchd registration are gone.