Code42 Incydr Agent NOT_SENDING_SECURITY_EVENTS: Diagnosing Why Endpoints Go Silent

The status can be triggered by five distinct conditions.

Cause 1: macOS Full Disk Access not granted. Incydr's file-monitoring component requires the Full Disk Access privacy permission on macOS 10.15 (Catalina) and later. Without it, the agent can connect to Code42's cloud, check in, and report its own health status, but it cannot access the file system events it needs to generate security event data. This is the most frequent cause in macOS environments where the MDM-deployed privacy profile was misconfigured or the agent was installed before the FDA profile was pushed.

Cause 2: macOS system extension not approved. On macOS 11 (Big Sur) and later, Incydr uses a user-space system extension rather than a kernel extension. If the system extension was not approved by the user or by an MDM-distributed approval payload, the event-capture component cannot load. The agent connects and checks in, but the extension that feeds it file system events is inactive.

Cause 3: Third-party security tool conflict on Windows. Code42 maintains a documented list of software known to conflict with the Code42 agent, primarily antivirus engines and EDR tools that register a minifilter driver at the same altitude as Incydr's driver. When both drivers attempt to intercept file system calls at the same altitude level, one or both can be blocked from loading. The Incydr agent service starts but cannot attach its file-system filter driver.

Cause 4: Virtualization software running on the endpoint. VirtualBox (versions with certain kernel driver configurations) and some Hyper-V configurations on Windows are documented as conflicting with the Code42 agent's low-level file monitoring. The conflict is at the driver level, not the application level, so disabling the guest VM does not resolve it if the host's virtualization drivers are still loaded.

Cause 5: User profile monitoring not enabled in the organization's policy. Incydr's file event collection can be scoped by policy. If the organization's watchlist or detection policy is configured to exclude the enrolled user's profile, or if the user was placed in a group with event collection disabled, the agent will check in without collecting events. This is a configuration state rather than a technical failure.

Start from the Incydr console, then move to the endpoint.

Step 1: Confirm the health status is NOT_SENDING_SECURITY_EVENTS and not a different status.

In the Incydr web console, navigate to Administration > Devices (or Endpoints, depending on your console version). Filter by health status NOT_SENDING_SECURITY_EVENTS. Confirm the affected endpoints are listed. Note whether they show a recent heartbeat timestamp. If the heartbeat is current (within the last hour), the agent is running and checking in. If the heartbeat is stale, the agent may actually be offline and the status may be misleading.

Step 2: Check the platform. macOS endpoints almost always need Full Disk Access or system extension investigation first. Windows endpoints need a driver conflict check first.

Step 3 (macOS): Verify Full Disk Access in System Settings.

On the endpoint, open System Settings > Privacy and Security > Full Disk Access. Look for Code42 (or "Code42 Agent") in the list. If it is not present or its toggle is off, Full Disk Access has not been granted.

Also check the system extensions:

systemextensionsctl list

Look for a Code42 extension entry. If it shows as activated enabled, the extension is running. If it shows activated waiting for user or is absent, the extension is pending user or MDM approval.

Step 4 (Windows): Check the Code42 minifilter driver status.

Open an elevated command prompt:

fltmc

This lists all loaded minifilter drivers with their altitude values. Look for the Code42 filter driver (typically named C42CloudArchive or similar). If it is absent, the driver did not load. Cross-reference any other drivers at or near the same altitude with Code42's known conflicts list.

Also check the Windows event log for driver load failures:

Get-WinEvent -LogName System | Where-Object {$_.Message -match 'code42' -or $_.Message -match 'C42'} | Select-Object -First 10 | Format-List Message

Step 5: Check the agent's local log on the endpoint.

On macOS:

log show --predicate 'subsystem == "com.code42"' --last 1h

On Windows, the Code42 agent log is located at:

C:\ProgramData\Code42\log\service.log.0

Search for entries containing error, failed, or permission. Specific strings to look for:

• Full Disk Access not granted or FDA permission denied: confirms Cause 1.
• System extension not active or extension not loaded: confirms Cause 2.
• Driver load failed or filter attach failed: confirms Cause 3 or 4.
• No watchlist match or user excluded from monitoring: confirms Cause 5.

Fix for Cause 1 (macOS Full Disk Access not granted):

For a small number of endpoints, grant FDA manually: System Settings > Privacy and Security > Full Disk Access > click the + button > navigate to and select the Code42 agent application.

For fleet deployment, push an FDA privacy preferences policy (PPPC) profile via MDM (Jamf, Kandji, or Mosyle). The profile must include:

• Identifier: the Code42 app bundle ID (verify the current bundle ID in your version of the Code42 agent release notes, as it has changed between major versions)
• IdentifierType: bundleID
• AllowedFiles: SystemPolicyAllFiles with Allow: true

After granting FDA, restart the Code42 agent service on the endpoint:

sudo launchctl stop com.code42.service && sudo launchctl start com.code42.service

Fix for Cause 2 (macOS system extension not approved):

If the extension is awaiting user approval (activated waiting for user), the user can approve it at the prompt, or an MDM can push a System Extension Policy payload approving Code42's extension by team ID. After approval, the extension activates without requiring a reboot on macOS 12 and later. On macOS 11, a reboot is required after extension approval.

Verify the extension is active after the fix:

systemextensionsctl list | grep -i code42

Expected output should include activated enabled.

Fix for Cause 3 (Windows driver conflict with third-party security software):

Add the Code42 agent's installation directory and process name to the exclusion list of the conflicting security tool. Code42's support documentation maintains a current list of exclusion paths and process names organized by security vendor. Apply these exclusions through the conflicting tool's management console rather than by modifying the conflicting tool's driver.

After adding exclusions, restart the Code42 agent service:

Restart-Service -Name "Code42 Service"

If the driver still does not load after exclusions are added, escalate to Code42 support with the output of fltmc and the driver load errors from the Windows event log.

Fix for Cause 4 (virtualization driver conflict):

If VirtualBox is installed, check whether Code42 has listed the installed version on its known conflicts page. In some cases, upgrading VirtualBox to the version that resolved the conflict is the fix. In others, the Code42 agent must be reinstalled after VirtualBox's kernel extension state changes. Consult the conflict documentation for the specific version combination.

Fix for Cause 5 (user excluded from monitoring policy):

In the Incydr console, navigate to the user's profile and confirm their watchlist membership and monitoring policy settings. Re-add the user to the appropriate watchlist or update the policy to include their profile. Changes propagate to the agent on its next policy sync, which occurs on the next heartbeat interval (typically every 15 minutes).

After applying the fix, do not rely on the health status badge alone. The status update can lag by up to one heartbeat interval.

Check for recent events in the Incydr console:

Navigate to Alerts or File Events in the Incydr console and filter by the specific endpoint (by device name or username). Set the time range to the last 30 minutes. If file events are appearing for the endpoint after the fix was applied, the agent is reporting correctly.

Generate a test event on the endpoint:

On macOS:

cp ~/Desktop/test.txt ~/Documents/incydr-test.txt

On Windows (PowerShell):

Copy-Item "$env:USERPROFILE\Desktop\test.txt" "$env:USERPROFILE\Documents\incydr-test.txt"

Wait two to three minutes and check whether a file copy event for incydr-test.txt appears in the Incydr event search. If it does, file event capture is working end-to-end.

Confirm the health status has cleared:

In the Incydr console, re-filter by NOT_SENDING_SECURITY_EVENTS. The resolved endpoint should no longer appear in that list after its next heartbeat, typically within 15 to 30 minutes of events resuming.

macOS: FDA was granted but events still do not appear. Full Disk Access changes sometimes require the Code42 agent service to be fully stopped and restarted (not just the app) before they take effect. Run sudo launchctl stop com.code42.service && sudo launchctl start com.code42.service. If that does not resolve it, check whether a MDM-distributed PPPC profile is overriding the manual FDA grant with a more restrictive policy.

Windows: Exclusions added but driver still fails to load. Some EDR tools with kernel-mode components apply additional controls beyond minifilter altitude. If the EDR uses a callback-based monitoring model in addition to a minifilter driver, adding a process exclusion may not be sufficient. In this case, raise the issue with Code42 support with the specific EDR vendor and version; Code42 maintains per-vendor guidance that goes beyond generic exclusion lists for the documented conflict cases.

Status returns to NOT_SENDING_SECURITY_EVENTS after a macOS OS update. macOS upgrades can reset system extension approvals, particularly across major version boundaries. After an OS upgrade, verify the system extension and FDA status on affected endpoints. This is a known operational pattern for all macOS security tools using system extensions, not specific to Code42.

Agent health shows Active in console but no events appear in event search. This can indicate a Cause 5 (policy exclusion) scenario that did not resolve on the previous heartbeat, or it can indicate the user's activity genuinely does not match Incydr's monitoring scope (for example, the monitoring policy only watches cloud upload activity and the user's test files were local). Broaden the event search filter to include all event types for that device to confirm whether any events are present.

Contact Code42 support when:

• Full Disk Access and system extension are both confirmed as approved and active, the driver or extension log shows no errors, and events still do not appear after a full agent restart.

• The Windows driver load failure persists after exclusions are applied and the conflicting tool's driver altitude has been verified to no longer conflict.

• NOT_SENDING_SECURITY_EVENTS returns cyclically within hours of being resolved on the same endpoint, with no OS update or policy change as a trigger. This pattern suggests an intermittent kernel-level conflict that requires Code42's engineering team to diagnose with a debug-level agent log.

When escalating, collect the following before opening the case:

• The Code42 agent version installed on the affected endpoint (visible in the Incydr console device detail or via the agent's local settings panel).
• The endpoint OS version and patch level.
• The output of fltmc (Windows) or systemextensionsctl list (macOS).
• The agent's local service log for the last 24 hours.
• A list of any third-party security tools installed on the endpoint and their versions.
• The timeline of when the status first appeared and what changed on the endpoint around that time (OS update, new software install, policy change).