What is kandji-daemon on Mac?

Last updated: 2026-08-05

What it is

kandji-daemon is the privileged background daemon inside Iru Agent, the application formerly known as Kandji Agent. It comes from Iru, the company and product previously called Kandji. It is not an Apple process and is not built into macOS.

Organizations install Iru Agent on enrolled Macs to extend Apple’s mobile device management system. kandji-daemon helps enforce settings assigned by administrators, manage applications, run administrator-provided scripts, and collect hardware and software inventory. It can also support optional endpoint-security capabilities when the organization has enabled them.

The name can look inconsistent with the current product branding. Executable names, launchd labels, bundle identifiers, and logging subsystems may still use kandji-daemon or io.kandji even though the application is now called Iru Agent. Identifiers associated with it include io.kandji.KandjiAgent and io.kandji.kandji-daemon. On a verified installation, the executable was located inside the Iru Agent application under /Library/Iru/.

Why it talks to the network

kandji-daemon contacts the organization’s tenant-specific Iru/Kandji device-management service over HTTPS. Recurring agent check-ins normally happen every 15 minutes. A synchronization started by an administrator or user can also cause it to connect outside that recurring schedule.

During these exchanges, the daemon retrieves current policy and Library Item state. It reports the results of enforcement work, sends application inventory, and checks whether the agent or managed applications need updates. When an administrator assigns software, the broader Iru system may download it from Iru/Kandji distribution or object-storage endpoints.

Additional traffic depends on which features the organization has enabled. Endpoint detection and response, vulnerability management, telemetry, and diagnostic features can all produce further exchanges. The precise data involved therefore depends on the organization’s licensed modules and configured policies.

Not every management-related connection on the Mac should be assigned to kandji-daemon. Apple’s MDM and APNs communication uses separate components, including mdmclient, and other Iru helper processes handle distinct parts of synchronization and software installation. Some application downloads, including larger ones, may be transferred by those helpers instead of kandji-daemon itself.

How much traffic is normal

There is no verified per-process traffic baseline for kandji-daemon, and no reliable vendor-published bandwidth figure was found. A specific daily total or expected number of megabytes would therefore be misleading.

The observable range can vary considerably. An idle, compliant Mac may show brief metadata exchanges during periodic check-ins. Assigning or updating software can lead to installer-sized transfers, although a separate Iru helper may carry some or all of a large download. Diagnostics and enabled security modules can add traffic whose volume depends on their activity and configuration.

For that reason, a large transfer is not automatically abnormal, while a quiet period does not mean the agent has stopped working. The useful questions are when the traffic occurred, whether software or policies were changing at the time, and whether another Iru process handled part of the transfer.

Can you turn it off

On an organization-managed Mac, the appropriate default is to keep kandji-daemon running. Apple does not provide a reliable System Settings switch specifically for this daemon. Login Items & Extensions may display the managed component, but the installed management profile is designed to prevent enrolled users from disabling its background services there.

Stopping or blocking the daemon can interrupt policy enforcement, inventory reporting, managed application installation and updates, administrator-provided scripts, and any enabled endpoint-security functions that depend on it. The Mac may consequently appear unhealthy or noncompliant in the organization’s management system.

That does not mean corporate access will always disappear immediately. Loss of access depends on whether the organization has configured compliance checks or conditional-access rules, so the outcome is organization-specific rather than universal.

Force-quitting the process is not a lasting removal method. Its launchd job uses KeepAlive, and the management service may attempt to reinstall an agent that is missing from an enrolled Mac. Proper removal should be handled by the organization’s administrator as part of device unenrollment. In some deployments, General > Device Management may allow removal of an enrollment profile, but that option is controlled by the organization, may be unavailable, and is not a dedicated kandji-daemon switch.

What people get wrong

• “It must be part of macOS.” It is not. kandji-daemon belongs to Iru, formerly Kandji, and arrives with the organization’s management agent rather than with macOS itself.

• “The unfamiliar name means it is malware or a cryptocurrency miner.” A strange process name is not evidence of either. kandji-daemon is expected on a Mac knowingly enrolled in Iru/Kandji management. If nobody expected the Mac to be managed, the installation should be investigated with the device owner or IT administrator.

• “Force Quit permanently disables it.” It does not. launchd is configured to keep the daemon running, and an enrolled device can receive an agent-reinstallation command if the agent is missing.

• “I can disable it like an ordinary login item.” That is not a supported control. The management profile is specifically intended to stop enrolled users from turning off these managed background services in System Settings.

• “Every MDM connection shown on the Mac belongs to kandji-daemon.” Apple’s mdmclient and APNs channel perform separate check-in and command-delivery work. Other Iru helpers can perform software installation and may account for some larger transfers.

• “Network activity proves it is capturing my browsing traffic.” Network use alone does not establish that. Documented purposes include management check-ins, inventory, software distribution, telemetry, diagnostics, and enabled security functions. Exactly what is collected depends on the organization’s modules and policies.

• “Blocking it always revokes corporate access immediately.” Not necessarily. That result requires organization-specific compliance or conditional-access enforcement and is not universal.

Seeing what it actually used

When a total cannot be inferred from a published baseline, the next step is to measure the process on the affected Mac over the time period you care about. Bytetally’s per-process statistics can show how much traffic kandji-daemon actually used, while separate Iru helpers should be checked independently. Compare the timing with policy changes, application assignments, updates, or diagnostic activity before deciding whether a transfer is unusual.

Related processes

Common questions