macOS idleassetsd download loop causing high CPU and battery drain

What I tried:

- Attempt: Block `idleassetsd` in LuLu

- Result: Downloads stopped, but it went into the restart loop (150-190% CPU).

- Attempt: Switch wallpaper to Sequoia

- Result: Not enough. The wallpaper settings (`~/Library/Application Support/com.apple.wallpaper/Store/Index.plist`) still had 59 Aerial entries, from 12 remembered displays and 18 Spaces.

- Attempt: Delete `~/Library/Application Support/com.apple.wallpaper/Store/Index.plist` (backed up first) and `killall WallpaperAgent`

- Result: Aerial entries went to 0. The loop continued, because the daemon downloads for itself, not for the wallpaper.

- Attempt: Delete `Aerial.sqlite` and the video cache

- Result: Made it worse: the daemon rebuilt the database and had more to fetch.

- Attempt: Allow it in LuLu

- Result: Restart loop stopped (`runs` stayed at 1), but it downloaded continuously.

- Attempt: `sudo launchctl disable system/com.apple.idleassetsd` and reboot

- Result: Did not stick. macOS removed the entry from `/private/var/db/com.apple.xpc.launchd/disabled.plist` at shutdown, so the daemon started at boot as usual.

- Attempt: `sudo launchctl kill SIGKILL ...`

- Result: Refused: "Not privileged to signal service". Force Quit in Activity Monitor works.

- Attempt: Free disk space (8.7 GB to 67 GB)

- Result: Stopped the delete-and-download cycle, but the scheduled downloads continued.

- Attempt: Block `sylvan.apple.com` in `/etc/hosts`

- Result: IPv4 only at first; IPv6 and already-open connections got through. With `::` added and the daemon restarted, it went back into the restart loop. Removed again.

- Attempt: Set root's `IdleScreenRefreshInterval` to `Never` and restart

- Result: Fixed. One process, 0% CPU, no downloads.

The fix

Ensure you do not use either a wallpaper or a screensaver that uses Aerial photos/videos. Let me know if you want to rebuild the wallpaper store from scratch.

`idleassetsd` runs as root and reads root's copy of the Aerial refresh setting. Set it to `Never`, then restart the daemon:

# 1. Check the current value (mine was ...Daily)
sudo defaults read /var/root/Library/Preferences/com.apple.TVScreenSaver IdleScreenRefreshInterval

# 2. Set it to Never
sudo defaults write /var/root/Library/Preferences/com.apple.TVScreenSaver \
    IdleScreenRefreshInterval TVScreenSaverIdleScreenRefreshIntervalNever

# 3. Restart the daemon so it re-reads the value
#    ("launchctl kill" is refused for this service even with sudo, so use
#    Activity Monitor > idleassetsd > Force Quit)

Do not block its network access (firewall, `/etc/hosts`). That puts it into a restart loop.

[Edited by Moderator]

There were three separate problems that made each other worse.

1. Scheduled downloads (the root cause)

The daemon downloads Aerial videos on a schedule, whether or not you use them. Decompiling TVIdleServices (using Ghidra, after extracting it from the system's shared library cache with ipsw) showed:

`+[TVISPreferencesUtility assetDownloadInterval]` reads the key `IdleScreenRefreshInterval` from the `com.apple.TVScreenSaver domain`:

- `TVScreenSaverIdleScreenRefreshIntervalNever` or not set: 0

- `TVScreenSaverIdleScreenRefreshIntervalDaily`: 1

- `TVScreenSaverIdleScreenRefreshIntervalWeekly`: 2

- `TVScreenSaverIdleScreenRefreshIntervalMonthly`: 3

`-[TVISAerialAssetService _needToDownloadAssetsToMeetMinimum]` returns "no" straight away when the interval is 0. Without that check it keeps a minimum number of videos on disk (`initialAssetCount: 4` in `Customer/entries.json`) and downloads more on a schedule (`nextScheduledAssetDownloadDate`).

The binary includes the log message "Asset download interval set to Never. Skipping asset download."

Root's value was ...Daily. The running process did not react to the change notification (`com.apple.TVScreenSaver.IdleScreenRefreshIntervalChanged`) in the middle of a batch, so it had to be restarted.

2. Full disk: download, delete, download again

With the disk at 99% full (8.7 GB free), the macOS service that frees space (deleted) kept asking `idleassetsd` for removable files, through its `CacheDelete` hook, several times a minute. Unpinned videos were removed, the count dropped below the minimum of 4, and the daemon downloaded them again. About 6.5 GB of the 11 GB went this way. Pinned videos are protected from this clean-up (`_protectedAssetURLs`).

3. Blocking makes it worse

When its network access fails, the daemon retries its catalog-image requests straight away with no delay: about 11,000 requests in 12 seconds. Memory grows until macOS kills it (`JETSAM_REASON_MEMORY_PERPROCESSLIMIT`). Then launchd starts it again the next time something calls it, about every 10 seconds. Over 4 days of uptime launchd counted 13,500+ launches.

This happened with every kind of block:

- LuLu firewall: the connection is refused (`NECP_CLIENT_ACTION_ADD_FLOW` ... Cannot allocate memory).

- `/etc/hosts` pointing `sylvan.apple.com` to 0.0.0.0 and :: the connection fails with "bad URL".

This looks like an Apple bug and is worth reporting through Feedback Assistant, with the `.diag` files attached.