Hi everyone,
as every year, here we are again with the million-dollar question: is Dropbox ready for macOS Golden Gate?
Has anyone already updated? How did it go?
Thanks.
🤗
Given the lack of replies, I decided to take one for the team.
I updated from the latest version of Tahoe available today, 17 September 2026, to Golden Gate, and there were no issues at all. It went almost as smoothly as if it were just a minor release.
Hey @cloudres, thanks for posting your question!
If you do decide to install the Dropbox app on your Mac and are having compatibility issues or any other kinds of issues, please let us know.
And of course, I will leave the thread open so that other users can comment on their experience with this.
Let me know if you need anything else!
Hey @Hannah, since no one answers... could you maybe do it yourself? Did the development team tell you if they tested the Mac app on the new MacOS?
It would be very useful to know, you know...
Hey @Hannah, I read that Mac OS Golden Gate forces users to use the file provider API, is this correct? The last time I tried to use it it was unusably bad, dangerously unreliable, I had to completely reformat my machine and go back to the kernel extension version. The limits on how many files and the lack of external drive support seem crazy to me. Has anything been done to fix this?
@cloudres how many files are you syncing on your dropbox? I hear the file provider api has a limit on the number of files
I’m not sure… is there a practical way to check? In any case, I’ve got almost 3 TB of files, which isn’t exactly a small amount.
@cloudres in some places I read the limit was 300000, in others 500000. I've got over a million so unless that's been fixed I don't even want to try it. I imagine there is software that can tell you, but I don't know what it is I'm afraid. I just got an alert from dropbox last time I tried telling me I had too many files
tldr; if you make virtual environments (.venv), especially via LLM/Claude/Codex etc, then you may have 100s of thousands more files than you think. This can kill File Provider. Moving them out of dropbox saves Dropbox and Spotlight a LOT of churn.
(maybe this goes in a different thread?)
hi, @hannah @cloudres in case it helps: i just tried to transfer my dropbox files to a new computer (with File Provider on). Everything came to a crash even with the most selective sync. Then with LLM help i diagnosed the problem by doing a full count of my files by directory. Turns out all my new LLM projects (via Claude cowork and .venv virtual environments) were creating (hidden) .venv folders in each project, EACH with 15k-25k files. So 20 projects = over 400,000 files just in the shadow docket. Not only making File Provider unusable, but Dropbox too, and explains why my spotlight was also crawling.
With the help of Claude and GPT (i always check with at least two), i was able to move all of the .venv (plus __pycache__, node_modules) out of Dropbox, recreate them within the projects where uv or venv pointing to ~/Developer/local . Now i'm syncing fine.
__pycache__
node_modules)
Also setting rules.dropboxignore to those (**/.venv/ **/venv **/pycache/ etc) in case they pop up. They won't autosync. rule: Environments are disposable, and caches should remain local.
rules.dropboxignore
Still not using File Provider because the risk of future mass explosions of files seems inevitable the way that LLMs can make things. And File Provider looks like it is not set up to handle contemporary development environments.
(ps. i do find it fascinating how our constraints continue to bounce between bandwidth, storage space, and now file numbers!) If Golden Gate does force File Provider… )
