dasd and appstoreagent High CPU Overnight on macOS 27: Fix

You close the lid on a healthy battery, and in the morning the Mac is warm, the fans have clearly been busy, and the charge has dropped further than a night of sleep should ever cost. If that started right after you upgraded to macOS 27 Golden Gate, there is a specific, well-documented suspect: two background processes called dasd and appstoreagent locked in a tight loop, reportedly every night from midnight. This guide explains what those two processes are, how Apple's background scheduler decides when they run, how to prove this particular bug is what you are seeing (rather than one of the half-dozen other things that heat up a Mac overnight), the exact community workaround and how to undo it, and what we can and cannot say about whether macOS 27.0.1 fixes it. Everything here is sourced from public reports and documentation; where something is unconfirmed, we say so.

Key Takeaways

• The bug is reported, reproducible for several people, and not yet acknowledged by Apple. A MacRumors thread started on 27 September describes appstoreagent and dasd spiking at midnight on two MacBooks, and other members report the same on a Mac Studio and a MacBook Pro. Apple has not published a known issue for it.
• The reported cause is an Apple Arcade task that never moves its own deadline. Independent write-ups say a preference called ArcadePayoutResetDate in com.apple.appstored stays stuck in the past, so the scheduler keeps re-running the task, reportedly 70 to 100 times a second.
• You can confirm it in two minutes without changing anything. Sort processes by CPU, read the preference, and peek at the unified log with a predicate. If the date is in the past and the log is flooded, that is your bug.
• The community fix is one defaults write plus killall appstoreagent. It pushes the date into the future. It is a workaround, it is reversible, and it is reported to hold for as long as the date you chose, for example seven days.
• We could not verify that 27.0.1 fixes it. Apple's 27.0.1 update (build 26A434) is described as fixing unspecified bugs. Nobody has yet posted a confirmed result for this issue, so test on your own Mac rather than assuming.
• Rule out the boring causes first. Spotlight and Photos analysis after an upgrade, Time Machine, iCloud sync and wake-for-network settings all produce overnight heat, and the decision table below tells you which process name points to which.

The Symptom: A Warm Mac and a Missing Battery at 9 AM

The original poster in the MacRumors thread gives the cleanest description of what this looks like. Since installing macOS 27 they saw CPU usage spike "exactly at midnight", with appstoreagent and dasd as the culprits, on both a MacBook Pro and a MacBook Air. The second time, they left both machines running overnight with iStat Menus open, and the load dropped again at 9 AM. A member with a Mac Studio and a MacBook Pro confirmed the same behaviour, and a third added a useful observation: you may never notice the CPU load if you do not run a system monitor, "but you will definitely notice your battery running down faster."

Some details worth keeping straight, all of them user observations and not Apple documentation:

• The timing is reported as midnight local time. One poster in the thread says the load ended at 9 AM. Another write-up describes the stuck timestamp as "today at 00:00:00" in the poster's time zone. Neither is Apple documentation; both are user observations.
• It is not new to the final release. The thread's original poster notes that people had already seen it in early betas, and a Chinese-language write-up from 24 June describes appstoreagent at over 100 percent CPU on a macOS 27 developer beta. So this is a long-lived bug that shipped rather than a fresh regression in the release build.

If that matches your Mac, read on. If your symptoms are heat during the day, or heat that lasts for days after the upgrade and not just at night, jump to the section on other causes, because the same fix will not help.

What dasd and appstoreagent Actually Are

Before running commands from strangers on the internet, it helps to know what you are poking.

appstoreagent: the App Store's background helper

appstoreagent is a per-user background agent that belongs to the App Store machinery. It checks for app updates, handles automatic downloads, verifies licences and keeps App Store state in sync. It is normally invisible and normally close to 0 percent CPU. One of the things it also does, and the part that matters here, is bookkeeping for Apple Arcade, which is why an Arcade-related preference shows up in its domain (com.apple.appstored).

dasd: the Duet Activity Scheduler

dasd is the Duet Activity Scheduler daemon, DAS for short, and it is one of the most important background processes on a Mac. Howard Oakley of The Eclectic Light Company, whose articles are the best public documentation on this subsystem, describes it like this: DAS maintains a list of scheduled activities and frequently evaluates them to work out which should run next. When a combined score for an activity exceeds a threshold, DAS decides to run it and tells Centralized Task Scheduling, CTS, to start it through XPC, Apple's lightweight inter-process communication.

Time Machine backups, software update clean-up, security scans, sync passes and dozens of routine maintenance jobs all go through this pipeline. In a July 2026 analysis, Oakley counted at least 701 non-identical activities submitted to DAS in the first minute or so after a boot on macOS 26.5.2, and notes that DAS and CTS are now largely responsible for the work done by the efficiency cores on Apple silicon Macs. In other words, dasd is a switchboard. When it burns CPU, it usually means something is feeding it work, or feeding it the same work over and over.

How the scheduler decides: scores, conditions and thresholds

Oakley's write-up lists the factors DAS folds into its score. They include battery level, whether a charger is connected, the energy budget, CPU usage, memory pressure, thermal state, network quality, whether the Mac is in a Power Nap state, and whether the user is actively using an app. Activities carry their own criteria, for example "do not run for 300 seconds after boot" for a first Time Machine backup, and DAS logs its decisions. He shows entries in the form "Decision: Can Proceed" and "Decision: Must Not Proceed" alongside a score and a threshold score.

Two properties of this design matter for our bug:

1. DAS runs work on a deadline as well as on conditions. An activity can be marked as due at a particular time. If it is overdue and its conditions are met, it runs.
2. The activity re-registers itself through its owner. After an activity runs, the process that owns it, here appstoreagent, tells the scheduler when it next wants to run. That is where a wrong date does damage.

The activity identifiers in the log look like 0:com.apple.softwareupdated.logs-cleanup:A2BBC8: a user ID, the activity name, and a short hex suffix that DAS assigns. The subsystem names to know are com.apple.duetactivityscheduler for DAS and com.apple.xpc.activity for CTS. You will use the first one shortly.

The Reported Cause: A Deadline That Never Moves Forward

Several people have independently traced this to the same place. The most detailed public write-up is issue 82 in a nix-config repository, which credits the Chinese developer whose blog post the MacRumors reply linked to. Its account, in summary:

• The task involved is com.apple.appstored.ArcadeResetPO, which the write-up describes as an Apple Arcade developer payout reset task.
• After it runs, a preference in the com.apple.appstored domain, ArcadePayoutResetDate, should advance to the next cycle. Instead, it stays locked to a past timestamp.
• dasd therefore sees the task as overdue and runs it immediately. appstoreagent re-registers it with the same expired time. The cycle repeats at roughly 70 to 100 times per second.
• The result is one core pinned, heavy unified logging, heat and battery drain.

The phobox360 script repository, written by a MacRumors member who says they found the bug independently, describes the same mechanism: an Apple Arcade background task named ArcadeResetPO repeatedly schedules itself in the past. That is two independent people reaching the same conclusion, which is more than a single anecdote but still not an Apple statement.

A separate, earlier report from June describes a beta-era variant. It blames database errors in Arcade code (a missing column in a SQLite table, and a log line about updating a task that is already running) and a tight loop of network-interface lookups. It is useful mainly as evidence that the problem predates the release. Its remedy, freezing the process with kill -STOP, disables App Store updates while frozen and is not what people are recommending now.

How to Confirm This Is Your Problem

Do these in order. Nothing in this section changes any setting. Ideally, run the first two while the Mac is misbehaving, which means shortly after midnight or first thing in the morning before you do anything else.

Step 1: Look at Activity Monitor

Open Activity Monitor from Applications > Utilities, click the CPU tab and sort by the % CPU column. You are looking for dasd and appstoreagent both near the top with sustained CPU, ideally with a large accumulated CPU Time. On a Mac with this bug, reports describe a full core, so a value near 100 percent for a single process on a multi-core machine is the pattern. dasd runs as root, so if you only see your own processes, set View > All Processes.

If the Mac has been idle all night, a huge CPU Time next to appstoreagent is a strong clue even after the spike has passed, because the column accumulates. The June write-up shows a top line with appstoreagent at 126.7 percent and a running time of over 284 minutes.

Step 2: Confirm from Terminal with top

Activity Monitor is fine, but Terminal gives you text you can paste into a forum thread. The first sample that top prints is an average since boot, so ask for two samples and read the second:

top -l 2 -n 10 -o cpu -stats pid,command,cpu,time

-o cpu sorts by CPU, -n 10 limits the list to ten processes, -l 2 takes two samples, and -stats chooses the columns. Read the second block. If dasd and appstoreagent are both in the top few and neither is near zero while the Mac is otherwise idle, that is consistent with the bug. As a shorter alternative, ps -axo pid,pcpu,time,comm -r | head lists the most CPU-hungry processes by current use.

Step 3: Read the Arcade date

This is the decisive test, because it checks the reported cause instead of the symptom. The phobox360 project's discussion identifies a locale-independent way to read the value. The key lives in the com.apple.appstored domain, and the value comes back in ISO 8601 format when read with plutil:

plutil -extract ArcadePayoutResetDate raw ~/Library/Preferences/com.apple.appstored.plist
defaults read com.apple.appstored ArcadePayoutResetDate
date -u +"%Y-%m-%dT%H:%M:%SZ"

The first command prints the stored date in the form 2026-09-26T22:00:00Z. The second prints the same thing through your locale settings, which is easier to read but, as the script's authors found, can be rendered differently on 12-hour locales, so use the first if you plan to compare programmatically. The third prints the current time in the same format so you can compare them by eye.

How to interpret it:

• Stored date is in the past (earlier than the current UTC time) while dasd and appstoreagent are busy: that matches the reported bug.
• Stored date is in the future and the processes are quiet: this bug is not what is happening to you.
• Stored date is in the future and the processes are still busy: something else is going on, or the loop has a cause that has not been described publicly. Use the process table further down.
• The key does not exist: the app has not created it yet, which is not evidence either way. A Mac that has never launched the App Store or Apple Arcade may lack it.

Save this output before you change anything. It is your record of the original value.

Step 4: Look at the unified log with an exact predicate

The log is where the "70 to 100 times per second" claim can be checked. The macOS log command takes an NSPredicate filter, and the shorthand process == "name" is documented in the log man page. To see the last few minutes from dasd in a compact one-line format:

log show --predicate 'process == "dasd"' --last 5m --style compact | head -50

To count how many lines it wrote in a single minute, which is a rough rate:

log show --predicate 'process == "dasd"' --last 1m --style compact | wc -l

On a healthy Mac, that number is modest. If this bug is active, expect a flood; the report says the loop causes heavy unified logging. You can also filter on the scheduler's subsystem, or search for the task name directly:

log show --predicate 'subsystem == "com.apple.duetactivityscheduler"' --last 2m --style compact | head -50
log show --predicate 'eventMessage CONTAINS "ArcadeResetPO"' --last 2m --style compact | head -50

The task name filter is the most specific. If ArcadeResetPO appears dozens of times in a minute, you have confirmed the reported bug. To watch it live rather than after the fact, use log stream with the same predicate:

log stream --predicate 'eventMessage CONTAINS "ArcadeResetPO"' --style compact

Press Control-C to stop. Two cautions. First, do not run log show over hours with a loose predicate on a Mac that has this bug, because the log can be enormous and the command will crawl. Keep the window short. Second, we are giving you documented syntax here, not a transcript of what your log will contain. Message wording can differ between builds, so if the first filter is empty, try the process filter before deciding the bug is absent.

Step 5: Check what kept the Mac awake

If the loop is running, you also want to know whether the Mac was awake for it or woke for it. Two pmset reads help.

pmset -g assertions
pmset -g log | grep -E "DarkWake|Wake "

The first shows current power assertions, meaning what is presently preventing sleep, such as a background task or a process holding the display awake. The second prints the wake history from the power log; each wake line has a "due to" reason, and a DarkWake is a partial wake where the Mac stays dark while it does background work. The manual page describes -g log as a history of sleeps, wakes and other power management events intended for administrators and debugging. A run of DarkWakes through the night, each triggered by a network or a maintenance reason, points at the scheduling path. An unbroken stretch of full wake points at something holding the Mac awake. Our Mac sleep problems guide walks through reading these lines in detail.

The Decision Table: Which Process Points to Which Cause

The reason this bug is confusing is that half a dozen unrelated jobs also show up as background CPU overnight. This table maps what you see in Activity Monitor to the most likely explanation. It is a diagnostic aid built from Apple documentation and the sources cited in this article, not a guarantee.

What you see near the top of CPU	Most likely cause	Normal or a problem?	First check
dasd and appstoreagent, both busy, often from midnight	The reported Arcade date loop	Problem (a reported bug)	Step 3: is ArcadePayoutResetDate in the past?
mds, mds_stores, mdworker_shared	Spotlight indexing	Normal for hours to a few days after an upgrade; a problem if it never settles	Our Spotlight reindexing guide
photoanalysisd, mediaanalysisd	Photos scanning your library (faces, scenes, objects)	Normal after an upgrade or a big import, especially when plugged in	Open Photos and check the analysis status in the library
backupd, backupd-helper, diskarbitrationd	Time Machine backup	Normal hourly; problem if it never completes	System Settings > General > Time Machine, and our Time Machine troubleshooting guide
bird, cloudd, fileproviderd	iCloud Drive or another file provider syncing	Normal during a large sync; a problem if it loops	Check iCloud Drive status and the size of recent changes
powerd, kernel_task high while idle	Thermal management or a power assertion	Depends; often a symptom rather than a cause	Step 5 and the assertions list
dasd alone, memory growing to many gigabytes	A different dasd memory issue, reported on macOS 27 betas by a third-party blog citing user reports	Problem, but a different one, and the date fix will not apply	Activity Monitor Memory tab
contactsd, peopled	The Contacts widget and call history database	A known Tahoe-era problem	Our peopled and contactsd guide
A third-party app or its helper	The app itself	Problem in that app	Quit it; check for an update

Two rules of thumb fall out of this table. First, the pairing matters: dasd on its own is a scheduler that is dispatching a lot of work, and the CPU is often being spent by the process it dispatches. dasd plus appstoreagent together, at a fixed time, is the pattern in the reports. Second, timing matters: indexing and photo analysis are heaviest right after the upgrade and fade, while a loop tied to midnight should recur every night.

The Community Workaround, Explained Line by Line

The fix that MacRumors members and the write-ups converged on is a single preference change. Here it is in the form posted in the thread, with the explanation the thread does not give you.

Before you change anything: save the original value

Take a copy of what is there, so you can put it back. Neither command modifies anything.

defaults read com.apple.appstored ArcadePayoutResetDate > ~/Desktop/arcade-date-before.txt
defaults export com.apple.appstored ~/Desktop/appstored-before.plist

The first writes the current date to a text file. The second exports the whole com.apple.appstored preference domain to a property list on your Desktop. If the first command prints "does not exist", the key is absent, and you can skip the first line.

The command

As posted on MacRumors and repeated in the nix-config issue, the seven-day version is:

defaults write com.apple.appstored ArcadePayoutResetDate -date "$(date -v+7d -u +"%Y-%m-%dT%H:%M:%SZ")" && killall appstoreagent

Take it apart:

• defaults write com.apple.appstored ArcadePayoutResetDate -date "..." writes a date value to the ArcadePayoutResetDate key in the App Store agent's preferences. The -date flag tells defaults the value is a date and not a string.
• $(date -v+7d -u +"%Y-%m-%dT%H:%M:%SZ") is the shell computing that date. date -v+7d is BSD date (the macOS one) adjusting the current time forward by seven days, -u uses UTC, and the format string produces an ISO 8601 timestamp ending in Z. GNU date from Homebrew coreutils uses different flags, so if you have replaced the system date in your path, run it as /bin/date.
• && runs the next part only if the write succeeded.
• killall appstoreagent terminates the running appstoreagent so that it restarts and reads the new preference. The system launches it on demand again, so this is not a permanent shutdown. If the App Store is in the middle of a download or update, this will interrupt it, so try to do it when nothing is updating.

Run this as your normal user, not with sudo. The preference belongs to your account, and the phobox360 project specifically tells its users to run without sudo. Writing preferences as root would create a file the agent may not read.

What you should see: within seconds of the restart, dasd and appstoreagent should drop to near zero in Activity Monitor. The write-up that first documented the command says the fix takes effect immediately. That is one user's reported result rather than something we can promise for your Mac.

What this does and does not change

• It changes one date. Nothing is deleted, no system file is touched, no protection is disabled. com.apple.appstored is an ordinary per-user preference domain.
• It does not fix the bug that made the date stale. It moves the deadline out of reach so the scheduler stops seeing the task as overdue. The reporters describe it as a workaround until Apple ships a real fix.
• It is not known to affect your Apple Arcade subscription or games. The task involved is described as a developer payout reset. But nobody has published a test of what happens to Arcade bookkeeping when the date is moved a long way out. The script author says as much about the more aggressive 2035 option. If you use Arcade heavily, prefer the short seven-day window.

Choosing a date: seven days, or years

The nix-config write-up uses 2099-01-01T00:00:00Z, which parks the task effectively forever:

defaults write com.apple.appstored ArcadePayoutResetDate -date "2099-01-01T00:00:00Z"
killall appstoreagent

That avoids repeating the fix weekly and is reported to shelve the task long term "without breaking App Store functionality", but that description is the reporter's, not something Apple has confirmed. The phobox360 script's optional durable mode uses 2035 and carries an explicit warning that its effect on Arcade bookkeeping has not been independently established. Our recommendation, which is a judgement and not a documented fact: start with seven days. If it works, you have learned the diagnosis was right at low risk, and you can decide later whether to go further.

How to undo it

There are two ways back, and it is worth knowing both before you need them.

Restore the saved value. If you saved the original date and it was a valid past date, writing it back returns you to the previous state, which, of course, is the state with the loop. In practice you only do this to test or to hand a clean state to Apple in a bug report. Use the ISO string from your text file:

defaults write com.apple.appstored ArcadePayoutResetDate -date "2026-09-26T22:00:00Z"
killall appstoreagent

Replace the example date with your own saved value.

Delete the key. This removes your override and lets the agent start without a stored value:

defaults delete com.apple.appstored ArcadePayoutResetDate
killall appstoreagent

Deleting a key is the standard defaults way of returning a setting to its default. What the App Store agent does when the key is missing on macOS 27 is not documented, and it may recreate a fresh, valid date or the buggy one. If the loop returns after deleting the key, apply the workaround again.

The script option, and how much to trust it

The dasd-arcade-loop-fix repository wraps the same change in a script with a dry run, a confirmation prompt, an automatic backup of the original value and a rollback command. At the time of writing it is a small project with almost no stars or forks, so it has not been widely reviewed. The sensible reading is that you should read the script before running it, or simply use the one-line command above, which does the same thing in a form you can see in full. If you do use the script, its documented flags are a dry run, the default one-week postponement, and --rollback. A pull request fixed an abort on 12-hour locales caused by how defaults read prints dates, which is a good reminder that shell scripts parsing preference output are fragile.

What not to do

• Do not kill dasd. It is root-owned, launchd restarts it immediately, and you cannot fix a scheduler by killing it. It also does not fix the reason the task is overdue.
• Do not kill -STOP or unload appstoreagent as a permanent measure. The June write-up used kill -STOP because nothing else held on a beta. It suspends the process, so App Store updates, downloads and licence checks stop until you resume it with kill -CONT.
• Do not disable System Integrity Protection or edit /System files. Nothing in any report needs it.
• Do not turn off automatic updates as your only remedy and call it fixed. One MacRumors reply suggests it, and it may reduce how often the agent wakes, but it does not address the reported cause: the task is an Arcade payout reset, not an update check. It also leaves you without automatic security updates for App Store apps. If you turn it off to test, turn it back on.

Why It Comes Back, and What to Do About It

If you used the seven-day command, the date you wrote is now a real, valid date, and the scheduler is content until that day passes. When it does, the stale-date condition is possible again. Reports say the loop can recur after about a week. The mechanism is what you would predict from the description of the bug: the fix moves the deadline, and the bug that fails to advance it properly is still there.

You have two options.

1. Repeat the command weekly. Put a reminder in Calendar. It is cheap and keeps your Arcade state close to normal.
2. Use a much later date. The 2099 form removes the chore. The trade-off is the one already described: less-tested territory for Arcade bookkeeping.

Does macOS 27.0.1 Fix It?

We do not know, and we would rather tell you that than guess.

What we can verify: Apple released macOS 27.0.1 on 28 September. According to The Eclectic Light Company's coverage, the new build number is 26A434, the update "apparently fixes unspecified bugs, together with one affecting Platform SingleSignOn", and there are no public security release notes. That article says nothing about CPU, battery, the App Store or Apple Arcade.

What the thread shows: after 27.0.1 came out, the original poster wrote "I wonder if this is fixed now in macOS 27.0.1." The reply that followed was about a different bug, a local-network permission problem for file extensions, and it confirmed that one was not fixed. Nobody in the thread reports a before-and-after result for the Arcade loop.

So the honest position is that it is unverified in both directions. Also note that Vague release notes are common, so a fix could be present without being listed.

How to find out on your own Mac in a way that produces useful evidence:

1. Update to 27.0.1 (System Settings > General > Software Update).
2. Before you apply any workaround, run Step 3 to read ArcadePayoutResetDate.
3. If you already applied the workaround, wait until the date you set has passed, or delete the key as described above and restart, then watch across midnight.
4. Look at top or Activity Monitor the next morning, and read the log with the task-name predicate.
5. Post what you find in the MacRumors thread. The people reading it are the same people who need the answer.

Other Causes of Overnight Heat and Battery Drain to Rule Out

Even if your dasd is guilty, it may not be alone. Upgrades trigger a stack of catch-up jobs, and it is common to have more than one problem at once. Work through these before you conclude the Arcade loop is the whole story.

Spotlight and Siri indexing after the upgrade

After a major upgrade macOS rebuilds parts of its search index, which shows up as mds, mds_stores and mdworker_shared. Apple's own guidance on unexpected wake notes that if Spotlight is indexing your disk, your Mac will not go to sleep, and a Mac that cannot sleep gets warm and drains the battery overnight. Indexing is finite: it runs hard for hours, sometimes a day or two on a big drive, then settles. The Arcade loop does not settle. Our guide to Spotlight reindexing after macOS 27 covers how to tell "still working" from "stuck", and the earlier report on macOS 26.6 shows the same pattern with Siri's index.

Photos analysis

photoanalysisd and mediaanalysisd scan your Photos library for people, scenes and objects. They are heaviest after an upgrade or an import, and they finish; there is no clock time at which they start. Leave the Mac plugged in overnight and see if the load fades over a few nights.

Time Machine

Time Machine backups run through the same scheduler. Oakley's write-up shows DAS declining a backup in the first seconds after startup because the activity requires a five-minute wait, which is an example of criteria at work. A first backup after an upgrade, or a backup to a slow network destination, can run for hours and heat the Mac. If backupd is the busy process, the Time Machine troubleshooting guide is the right place, and Oakley's article on scheduling and dispatch of backups explains why a backup may start at odd moments.

Power Nap and Wake for network access

Apple's sleep and wake settings page says that Power Nap lets the Mac update itself while asleep, and that "Wake for network access" lets it wake briefly so other users can access shared services. On a laptop both are under System Settings > Battery > Options. Apple's unexpected wake page lists disabling wake for network access and turning off sharing services among its suggestions. The pmset manual page says womp is the Terminal equivalent of "Wake for network access" and that powernap applies on supported machines. Availability of Power Nap varies by model, so do not be surprised if you do not see it.

To check your current values without changing them:

pmset -g | grep -E "powernap|womp"

Turning both off is a fair experiment if your pmset -g log shows regular DarkWakes overnight. It will not fix the Arcade loop, which happens while the Mac is awake or in a wake for maintenance, but it removes noise from your diagnosis. Make one change at a time so you can tell what helped.

Troubleshooting Common Issues

The processes are still busy after the command

Symptoms: You ran the defaults write and killall, but dasd and appstoreagent are still near the top of Activity Monitor.

Cause: Several possibilities. The killall may not have matched, so the old process is still running with the old date cached. The write may have failed silently, for example because of a typo in the domain. You may be seeing a different cause altogether.

Solution:

1. Read the value back with plutil -extract ArcadePayoutResetDate raw ~/Library/Preferences/com.apple.appstored.plist and confirm it is in the future.
2. Run killall appstoreagent again, then check with Activity Monitor whether the process restarted with a new PID.
3. Re-run the task-name log predicate for one minute. If ArcadeResetPO no longer appears but the CPU is still high, the cause is something else, and the process table above is your next stop.

plutil -extract ArcadePayoutResetDate raw ~/Library/Preferences/com.apple.appstored.plist
pgrep -l appstoreagent

If that does not work: Restart the Mac once. A restart clears cached preferences and any stuck scheduler state. If the date is still valid after the restart and the load remains, treat it as a different bug and gather Step 2 and Step 4 output before asking for help.

The loop returns a week later

Symptoms: A quiet week, then the midnight spike returns.

Cause: Your seven-day date has passed and the underlying bug is still present.

Solution: Run the command again, or choose a later date as discussed above. If you would rather not repeat it, decide on a longer window knowingly, remembering that its effect on Arcade bookkeeping is not documented.

The Mac still drains overnight but the processes look quiet

Symptoms: dasd and appstoreagent are at zero and the battery still falls.

Cause: Heat and drain during sleep often come from wakes and assertions, not from CPU.

Solution: Read pmset -g log for the overnight window and see how often the Mac woke and why. Check pmset -g assertions for something that prevents sleep. Our Mac sleep problems guide and the macOS Tahoe battery drain guide go through the common offenders, and the advanced battery diagnostics guide covers reading the battery data in more depth.

FAQ

Why are dasd and appstoreagent using so much CPU on macOS 27?

Reports from MacRumors members and independent write-ups say an Apple Arcade task, ArcadeResetPO, keeps a stored date in the past, so the scheduler reruns it constantly, possibly 70 to 100 times a second. Apple has not confirmed this. The pattern is one core pinned, often starting at midnight, with heat and faster battery drain.

Is it safe to run the defaults write command for ArcadePayoutResetDate?

It changes a single per-user preference and does not touch system files, and it can be undone by deleting the key or restoring a saved value. It is a community workaround, not Apple guidance, and its effect on Arcade bookkeeping over long periods is undocumented. Save the original value first, and prefer a short window.

Does macOS 27.0.1 fix the dasd and appstoreagent loop?

We could not verify that. Apple's 27.0.1 update, build 26A434, is reported as fixing unspecified bugs and one Platform SSO problem, with no mention of this. The one MacRumors post asking about it drew a reply about a different bug. Test on your own Mac by reading the date across midnight.

How do I know it is this bug and not Spotlight or Photos?

Read the stored date with plutil and compare it with the current UTC time. If it is in the past while dasd and appstoreagent are busy, and the log shows the ArcadeResetPO task repeating, it is this bug. Spotlight shows as mds processes, and Photos as photoanalysisd, with no fixed midnight start.

Why does the problem come back after a week?

The workaround moves the reset date a week ahead. When that date passes, the underlying bug that fails to advance it can strike again, so the loop returns. Reporters describe it recurring after about a week. You can repeat the command weekly or choose a later date, accepting that long dates are less tested.

Will disabling automatic App Store updates stop it?

One MacRumors reply says it quiets the processes, but it does not address the reported cause, which is an Arcade payout task and not an update check. It also means you stop receiving automatic App Store app updates. Treat it as a trade-off to test, not a fix, and turn updates back on if it does not help.

Can I just kill dasd or appstoreagent?

Killing appstoreagent stops the spike briefly, but the system relaunches it on demand and the stale date remains, so the loop resumes. dasd is a root-owned scheduler that launchd restarts at once. Freezing appstoreagent with kill -STOP works but stops App Store updates and licence checks until you resume it.

Does the fix affect my Apple Arcade games or subscription?

Nothing in the public reports says so. The task is described as a developer payout reset, and the workaround only changes one date. But no one has published a test of moving it years into the future, and the script author explicitly says the effect on Arcade bookkeeping has not been established. Use a short window if you play Arcade.

Conclusion

The pattern behind a Mac that runs hot and flat overnight on macOS 27 is, in a growing number of reports, a scheduler loop: dasd dispatching, and appstoreagent re-registering, an Apple Arcade task whose date never moves forward. It is cheap to confirm without changing anything: read the stored date, compare it with UTC, and look for the task name in the log. If the date is in the past, the one-line community workaround is reported to stop the loop at once, and it is easy to reverse.

Keep your expectations honest. It is a workaround that needs repeating unless you accept a longer date, Apple has not acknowledged it, and we cannot tell you that 27.0.1 or any later update fixes it. If the date check comes back clean, do not force the diagnosis; work through Spotlight, Photos, Time Machine, iCloud and wake settings, one at a time, using the decision table above.

For deeper dives, our Spotlight reindexing guide covers the most common legitimate cause of a hot Mac after an upgrade, and the Mac sleep problems guide covers wake and assertion problems. If a different process is your culprit, the peopled and contactsd guide may match it. And if you find out whether 27.0.1 changed anything on your Mac, tell the people in the MacRumors thread.

Have questions or tips to share? We would love to hear about your experience in the comments below.

Related reading: Spotlight reindexing after macOS 27, Mac hot and draining battery after macOS 26.6, macOS Tahoe battery drain complete fix guide, macOS 27 Golden Gate release-day guide