macOS 27 Golden Gate: the dasd memory leak explained

macOS 27 Golden Gate's beta releases introduced a real, widely reported bug: a background process called dasd can climb to 20-70GB of memory, forcing your Mac into swap and eventually freezing it. This affects Macs from M1 through M5. Apple has attempted fixes in later betas, but reports of the issue persisting continue. Here's what dasd actually does, why it's leaking, and what genuinely helps while you wait for a permanent fix.

If Activity Monitor shows a process called dasd quietly climbing past 10, 20, even 70GB of memory on macOS 27 Golden Gate, you're not imagining it and you haven't broken anything. This is a documented bug affecting beta users across the current Mac lineup.

What is dasd?

dasd stands for Duet Activity Scheduler Daemon. It's part of macOS's machine-learning system that predicts which apps you're likely to open next, based on time of day, location, and your usage patterns, so it can preload them faster. It's been a normal, low-profile background process for years. On Golden Gate's beta builds, something in its prediction logic broke: instead of releasing memory once a prediction cycle finishes, it keeps accumulating, indefinitely, until the system runs out of room.

How bad is the leak?

Reports on MacRumors forums describe dasd climbing to 40GB and beyond, with some users hitting 70GB before their Mac became unresponsive and threw "you are out of system memory" alerts. The leak has been confirmed on M1, M2, M3, M4, and M5 Macs, across a wide range of RAM configurations from 16GB up to 128GB, meaning more memory doesn't make you immune, it just takes longer to run out.

Apple addressed the issue in beta 3 after it was first widely reported in beta 2. That said, some users report the problem persisting into later developer betas and even the first public beta, so treat this as an ongoing situation rather than a fully closed case until you've confirmed your specific build is unaffected.

How to check if you're affected

Open Activity Monitor (Command-Space, type "Activity Monitor", press Return), click the Memory tab, and sort by Memory usage. If dasd appears near the top of the list showing several gigabytes or more, and it keeps climbing rather than settling, you're seeing this bug rather than normal background activity.

What actually helps right now

Update to the latest beta. If you're running a Golden Gate beta with this issue, checking for a newer beta build via Software Update is the first thing to try, since Apple has iterated on this specific bug across releases.

Force-quit dasd from Activity Monitor. Select the process and click the Stop button (the X in a circle at the top-left of the window). macOS will relaunch it automatically since it's a system daemon, and the relaunch starts with a clean memory slate. This is safe: you're not deleting anything, just restarting one background process.

Restart your Mac. A full restart clears the accumulated leak completely, though it will begin climbing again from a clean baseline. On a build where the leak is severe, a restart may be needed more than once a day, which is a real inconvenience while you wait for Apple's permanent fix.

Some tech sites report a more invasive workaround involving deleting specific files under /private/var/db/powerlog via Terminal. We'd be cautious recommending this: it requires administrator access to modify a system database, isn't an officially supported fix from Apple, and carries real risk if you're not comfortable in Terminal. Force-quitting the process or restarting achieves a similar result with far less risk.

Where a memory-relief tool fits in

Because this specific leak is isolated to one process, force-quitting dasd (or a restart) is the direct fix, and no third-party tool can patch Apple's own beta bug. What a one-click memory tool like Shiny genuinely helps with is the broader symptom: if dasd (or anything else) has already eaten a large chunk of your available RAM and you need working memory back immediately without a full restart, asking macOS to release what it's holding buys you time between the moments you force-quit the offending process. It's a stopgap for the symptom, not a fix for Apple's bug, and we want to be upfront about that distinction.

Should you be on the Golden Gate beta at all?

If you rely on your Mac for work and this bug is hitting you hard, the honest answer is to hold off on the beta until Apple ships a public release with this resolved, or revert to the current stable macOS Tahoe release if you installed the beta on your only Mac. Beta software exists precisely to surface bugs like this before the public release; being affected by one isn't a sign anything is wrong with your specific machine.

For more on evaluating whether a fresh macOS release is worth installing early, see macOS Tahoe slow performance and the macOS Sequoia memory leak guide, which covered a similar early-release memory bug the previous year.

Why prediction daemons leak memory in the first place

It's worth understanding the general pattern, since this isn't the first time a background prediction or scheduling process has caused a memory leak on macOS, and it likely won't be the last. These daemons work by building up a model of your behaviour in memory: which apps you open, when, and in what sequence, so they can act on that model quickly rather than recalculating from scratch every time. The bug class that produces leaks like this one is almost always the same: the process correctly builds up its working model, but a code path that's supposed to release the OLD model once a new one is calculated fails to run, so both the old and new versions sit in memory simultaneously, indefinitely. Multiply that across enough prediction cycles over a day, and you get the kind of unbounded growth reported in these threads.

Is your data at risk?

No. This is purely a memory-management bug, not a privacy or security issue. dasd's prediction model is built entirely from your own local usage patterns and stays on your Mac; nothing about this bug involves data leaving your machine or being exposed to anyone else. The only consequence is the one described above: memory that should be released isn't, until you force-quit the process or restart.

What to watch for once Apple ships a fix

When Apple does resolve this in a future beta or the public release, the practical sign to look for is dasd's memory usage plateauing rather than climbing indefinitely. A small, stable footprint, similar to what dasd has held for years prior to Golden Gate, is the expected healthy behaviour. If you're still seeing unbounded growth on a build that claims to fix this, it's worth filing feedback through Apple's own Feedback Assistant app, which is how these beta issues get tracked and prioritised internally.

Common follow-up questions

What is dasd on Mac?
dasd (Duet Activity Scheduler Daemon) is a macOS background process that uses machine learning to predict which apps you're likely to open next, so it can preload them for faster launches. It's a normal, longstanding part of macOS, not something new or inherently suspicious.
Why is dasd using so much memory on macOS 27?
A bug in Golden Gate's beta releases causes dasd's prediction logic to accumulate memory instead of releasing it after each cycle, leading to reports of 20-70GB of usage. Apple attempted a fix in beta 3, though some users report the issue persisting in later builds.
Is it safe to force-quit dasd?
Yes. Select it in Activity Monitor's Memory tab and click Stop. It's a system daemon, so macOS relaunches it automatically, and the relaunch starts with a clean memory footprint. This does not delete any files or settings.
Has Apple fixed the dasd memory leak?
Apple shipped a fix in beta 3 after the bug was widely reported in beta 2, but some users report the problem persisting in developer beta 3 and the first public beta. Check for the latest available beta build, since this has been an area of active iteration.
Should I avoid installing macOS 27 Golden Gate because of this?
If your Mac is your only machine and you rely on it for work, it's reasonable to wait for a public release with this confirmed fixed, or to stay on the current stable Tahoe release. Beta software is inherently more likely to have unresolved issues like this one.