What is remoted on Mac, and why is it using the network?

Last updated: 2026-07-31

What it is

remoted is the built-in macOS Remote Service Discovery daemon. Its expected executable is /usr/libexec/remoted, and its Apple platform identifier is com.apple.remoted. launchd keeps the daemon available so it can discover reachable remote devices, learn which system services they offer, and provide communication channels for authorized system components.

Its scope includes connections involving CoreDevice, RemoteXPC, USB network interfaces, Bonjour, virtualization, and some embedded-device services. That makes remoted part of a broader device and system-service communication layer rather than a user-facing remote-access application. Apple has not published a complete mapping between every device category, consumer feature, and internal service that may use this layer.

Despite its name, remoted is not the server for Apple Remote Desktop, Remote Login, or Screen Sharing. Apple Remote Desktop uses separate components such as ARDAgent. Seeing remoted running is therefore normal on macOS and does not, by itself, indicate that another person has opened or is controlling the Mac.

Why it talks to the network

Several independently verified conditions can cause remoted to communicate. It may react when a device appears on a USB/NCM network interface, when Bonjour discovers another Remote Service Discovery node on the local network, or when CoreDevice or Xcode requests a connection to a paired physical Apple device. Virtual-machine and compute-platform backends can also activate the relevant discovery or communication paths.

The other endpoint may be a CoreDevice-compatible device, an embedded or bridge/display device associated with the Mac, a virtual machine, or a compute node. These categories describe the supported communication paths, but they do not establish a complete product-by-product list. Apple has not fully documented which individual Apple products and features correspond to every endpoint or service that remoted can discover.

The network label can also be misleading here. Some activity may use Bonjour on a local or link-local network, while other activity can travel over a direct device interface such as USB NCM. The local executable contains communication paths involving Bonjour, USB NCM, and IPv6 interfaces. However, the available evidence does not justify a blanket claim that every byte from remoted is local or that the daemon can never produce wide-area network traffic.

There is also no reliable first-party evidence that remoted specifically or continuously runs Handoff, AirPlay, or iPhone Mirroring. Those feature-level attributions remain unverified and should not be inferred from the process name alone.

How much traffic is normal

Apple has not published a normal traffic baseline for remoted. There is no verified daily or monthly byte range, and no reliable MB threshold that can separate normal behavior from a problem across all Macs. Hardware connections, paired devices, development activity, virtual machines, and the services requested by other system components can all change what the daemon needs to do.

During idle discovery, its activity should generally consist of intermittent, low-volume control messages, handshakes, and service descriptions. Much of that activity commonly occurs through Bonjour, local or link-local networking, or direct device interfaces. In that state, the traffic would normally be much smaller than a video stream or an application download.

Traffic can rise noticeably when an upper-layer service uses the established channel to move diagnostic material, symbols, installation content, or other data. A larger transfer therefore cannot be evaluated using discovery traffic alone. At the same time, Apple has not documented a universal upper limit or guaranteed that all communication remains on the local network. Any exact number presented as the normal allowance for remoted would go beyond the available evidence.

Can you turn it off

The practical conclusion is to keep remoted enabled. Apple does not provide a System Settings path or a supported switch for turning off the daemon itself. Disabling Remote Login, Remote Management, a sharing option, or a Continuity feature is not the same as safely disabling remoted.

Its local launchd definition includes KeepAlive behavior, and the historical man page describes no configuration options. Forcing the launchd job off may break physical-device discovery, Xcode or CoreDevice communication with paired devices, RemoteXPC system services, virtual-machine integrations, or embedded-device components. Apple has not exposed a supported way to disable only one of those internal communication paths while leaving the others intact.

Using permanent launchd changes merely to reduce traffic is therefore a poor trade. The discovery phase is generally low-volume control activity, while the disabled job can affect several unrelated device-service paths. If a particular transfer looks unusual, measuring the process during the triggering activity gives more useful evidence than treating the daemon’s presence as the problem.

What people get wrong

• “remoted is Apple Remote Desktop, Remote Login, or Screen Sharing.” It is not. Apple defines it as the Remote Service Discovery daemon. Apple Remote Desktop relies on separate components, including ARDAgent, and the name remoted does not make it a general remote-control server.

• “If remoted is running, someone is remotely controlling this Mac.” Its presence does not establish that. remoted is a default resident system component maintained by launchd. A process using the same name from a different path, or an executable with an abnormal signature, should be investigated separately; the normal /usr/libexec/remoted process is not evidence of an intruder.

• “It constantly scans nearby devices and specifically runs Handoff, AirPlay, and iPhone Mirroring.” The verified material supports device and service discovery through mechanisms including Bonjour, USB NCM, CoreDevice, RemoteXPC, and virtualization. It does not provide reliable first-party support for assigning those three consumer features specifically or continuously to remoted. Those claims remain unverified.

• “Turning off Remote Login, Remote Management, or every Sharing option will stop remoted.” Those settings control different user-facing services. They do not provide a switch for this daemon. The local launchd definition uses KeepAlive, and the historical remoted man page lists no configuration options.

• “Permanently disabling it with launchctl is a sensible way to save bandwidth.” Discovery normally involves intermittent control traffic, while the daemon supports multiple system device-communication paths. Forcing it off can disrupt device discovery, CoreDevice and Xcode connections, RemoteXPC, virtualization, and embedded-device services. The potential saving is not supported by a published baseline, while the functional consequences are concrete.

• “Every byte attributed to remoted in Activity Monitor is an internet download.” The executable has verified paths for Bonjour, USB NCM, and IPv6 interface communication, so local, link-local, and direct-device activity can all appear as network traffic. That does not prove the opposite extreme either: Apple has not guaranteed that remoted only communicates locally or can never use a wide-area path.

Seeing what it actually used

The next step is to measure remoted during the period you care about instead of assigning it an unsupported fixed allowance. Bytetally’s per-process statistics can show how much traffic was attributed to remoted; compare an idle period with the device connection, Xcode session, or virtual-machine activity you are investigating. Treat that measurement as evidence about your Mac and that time window, not as a universal baseline.

Related processes

Common questions