Fix “Apple Remote Desktop or Another Administration Application is Currently Running” Error

If you hit “Apple Remote Desktop or another administration application is currently running” and went looking for a fix, you almost certainly landed on some version of the same two steps: kill the Remote Desktop processes, then run kickstart to re-activate Remote Management. An earlier version of this page recommended exactly that, including a launchd plist to unload and reload.

That advice was wrong, and it’s worth spelling out how — because those same commands are still being copied between forum answers and blog posts, and this page was one of the places doing the copying. Below is what breaks, checked against macOS 26.5.2 (build 25F84) and against Apple’s own documentation.

The plist path in the old version isn’t there

The old text told you to run sudo launchctl unload /System/Library/LaunchAgents/com.apple.RemoteDesktop.agent.plist. On macOS 26.5.2 there is no such file:

$ ls /System/Library/LaunchAgents/com.apple.RemoteDesktop.agent.plist
ls: /System/Library/LaunchAgents/com.apple.RemoteDesktop.agent.plist: No such file or directory

Whether it ever existed under that name on some older release isn’t something this page can settle — that would take a machine running one. What can be shown is where the wrong name most likely came from. The real file drops the .agent; the label inside the file keeps it:

$ plutil -p /System/Library/LaunchAgents/com.apple.RemoteDesktop.plist
{
  "KeepAlive" => {
    "PathState" => {
      "/Library/Application Support/Apple/Remote Desktop/RemoteManagement.launchd" => true
    }
  }
  "Label" => "com.apple.RemoteDesktop.agent"
  "LimitLoadToSessionType" => [
    0 => "Aqua"
    1 => "LoginWindow"
  ]
  "MachServices" => {
    "com.apple.RemoteDesktop.agent" => true
  }
  "ProcessType" => "Standard"
  "Program" => "/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent"
}

Label plus .plist gives you com.apple.RemoteDesktop.agent.plist — a reasonable guess, since plenty of launchd files do follow that convention. This one doesn’t.

Two more reasons that unload was never going to work

Even with the correct filename, the command has two further problems. First, /System/Library/LaunchAgents lives on the sealed system snapshot, mounted read-only with SIP enabled:

$ mount | grep 'on / '
/dev/disk3s1s1 on / (apfs, sealed, local, read-only, journaled)

Second — and this one survives even if you sidestep the seal — the sudo is aimed at the wrong place. The plist above sets LimitLoadToSessionType to Aqua and LoginWindow, which makes this a GUI agent living in a per-user domain. But man launchctl is explicit about what running the legacy subcommands as root does:

LEGACY SUBCOMMANDS
     Legacy subcommands select the target domain based on whether they are
     executed as root or not. When executed as root, they target the system
     domain.

     load | unload [-wF] [-S sessiontype] [-D searchpath] paths ...
	      Recommended alternative subcommands: bootstrap | bootout | enable
	      | disable

So sudo launchctl unload targets the system domain, and the agent isn’t in the system domain:

$ launchctl print system/com.apple.RemoteDesktop.agent
Bad request.
Could not find service "com.apple.RemoteDesktop.agent" in domain for system

Note the second thing that man page says: load and unload are filed under legacy, with bootstrap and bootout named as the recommended replacements. The old version of this article didn’t mention that at all — it was handing out a deprecated verb, pointed at a nonexistent file, on a read-only volume, in the wrong domain.

Why killing the process doesn’t stick

Look again at the top of that plist. KeepAlive contains a PathState dictionary pointing at a marker file, set to true. man launchd.plist describes what that means:

	   PathState <dictionary of booleans>
	   Each key in this dictionary is a file-system path. If the value of
	   the key is true, then the job will be kept alive as long as the path
	   exists.  If false, the job will be kept alive in the inverse
	   condition. The intent of this feature is that two or more jobs may
	   ...

And the marker file is a one-word semaphore:

$ cat "/Library/Application Support/Apple/Remote Desktop/RemoteManagement.launchd"
enabled

That chain explains the whole frustration. While that file exists, launchd’s job is to keep ARDAgent alive. Kill the process and launchd puts it back — that’s not a bug, that’s the configuration working as written. The process was never the lever; the marker file is the thing launchd is actually watching. Every “kill the stuck process” recipe for this error is fighting an object that is designed to come back.

kickstart: Apple has said no since macOS 12.1

The binary is real and still shipping — /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart, a 1,913-line Perl script whose usage text still lists -activate, -configure, -access, -privs and the rest. That’s why the recipe looks alive.

Apple’s Remote Desktop documentation, on the page for enabling Remote Management, says otherwise:

In macOS 12.1 or later, Screen Sharing can’t be enabled by the kickstart command-line tool.

The same page adds that you can use a mobile device management (MDM) solution to enable Remote Management instead. So the old article’s claim to cover “up to macOS 14 Sonoma” was promising a fix across a range of releases where Apple says the central command doesn’t do the job.

The script hasn’t been left ignorant of this. Reading its message table, two of the strings it can print during -activate are:

MSG_TRUST_RESTRICTED => 'Screen control might be disabled. Screen Sharing or Remote Management must be enabled from System Settings or via MDM.',

MSG_TRUST_ABSENT => 'Screen recording might be disabled. Screen Sharing or Remote Management must be enabled from System Settings or via MDM.',

Apple’s own tool tells you to go use System Settings or MDM — and the code prints those two in red, which nothing else in the message table gets. But it doesn’t refuse the command. Following the activate path in the script, it goes on to write the marker file and print 'Activated Remote Management.' regardless. That combination is the trap: a command that reports success while the thing you wanted stays off. It would explain how the recipe keeps getting passed along — running it produces no error to notice.

And killall “Remote Desktop” is pointed at the wrong Mac

One smaller mix-up, since the old version called it the best solution. Remote Desktop is the admin console application, the one running on the administrator’s own machine. The error under discussion appears on the target Mac, where that application generally isn’t installed at all — what’s there is ARDAgent, out of the RemoteManagement folder. Killing “Remote Desktop” on the target usually kills nothing, and a command that matches no process is indistinguishable from one that fixed something.

So what actually clears it?

Honest answer: on macOS 12.1 and later there’s no clean command-line fix, and this page shouldn’t have implied there was one. What Apple documents is the checkbox — open Sharing on the target Mac and toggle Remote Management off and back on. In Apple’s words, “If Remote Management is already selected, deselect it and select it again.” Whether that toggle rewrites the same marker file shown above is an inference rather than something demonstrated here, but it is the supported path, and at fleet scale Apple points at MDM rather than at a shell.

That’s an unsatisfying answer for anyone who reached this page over SSH with no one sitting at the target machine. It’s still the accurate one. The useful thing to take away isn’t a new command to paste — it’s that the old commands were broken in four independent ways at once: a filename that doesn’t exist, a volume that can’t be written, a domain that doesn’t hold the agent, and a job configured to respawn. Fixing any one of them still leaves the other three.

If the toggle doesn’t clear it and you can’t reach the machine physically or through MDM, that’s the point where the answer is a restart of the target or a trip to the desk — not another round of kickstart flags. Nothing in the tool is going to enable Screen Sharing for you on a current macOS, and repeating the command with different arguments won’t change that.