Your workflow is unique 👨💻 - tell us how you use Dropbox here.
macOS 26.3 (M4) Dropbox v243.3.6895: CxSupportTool window loop + Chromium 102 renderer abort
Application Affected: Dropbox Desktop (macOS) Device: MacBook Pro M4 Max, 36GB RAM Operating System: macOS 26.3 Tahoe (Apple Silicon) Dropbox App Version: 243.3.6895 (Electron 19.1.9-dropbox.50 / Chromium 102) Subscription: Dropbox Pro Question / Issue Two distinct bugs prevent normal use of the Dropbox desktop client: CxSupportTool diagnostic window launches automatically every 2-12 seconds whenever any Dropbox UI is opened (Settings, tray popup), displaying raw sync engine debug output to the end user. This makes the Settings UI unusable and predates macOS Tahoe. Renderer processes abort on macOS 26 due to a FATAL:logging.cc failure in Chromium 102, causing IPC errors and renderer death. This is macOS 26-specific. Bug 1: CxSupportTool Diagnostic Overlay Reproduction Steps Launch Dropbox normally Click the Dropbox menu bar icon Open Settings/Preferences (or interact with the tray UI) Wait 2-12 seconds A 960x540 window titled "CX Support Tool" appears, showing raw sync engine diagnostics: PhaseInformation, SyncStatus, EngineWaitTracker, PendingSetTracker Pending set count (600-900+ items), capped: true Closing the window does not help - it reappears within seconds The cycle repeats indefinitely, making Settings navigation impossible Observed Behavior The diagnostic window is not a crash dialog - the main process and renderer processes remain alive. The window is a fully rendered BrowserWindow ( cxSupportToolView ) spawned by the Dropbox "journey" system. It displays the output of fetchEngineDebugInfo() , which is internal sync engine state not meant for end users. The issue persists across: Multiple macOS versions (predates Tahoe) Clean reinstalls of Dropbox Clearing all local caches and crash data Root Cause Analysis I extracted and analyzed app.asar and traced the trigger chain: SyncErrorServiceImpl detects sync errors → fetchEngineDebugInfo() IPC call → CxSupportToolController.launchJourney() (module 898 in main.js) → spawnViewWithServices() creates BrowserWindow (960×540) → cxSupportToolView renders engine debug info CxSupportToolController (in main.js module 898) extends BaseUserJourneyController and is registered as: registerUserJourney( UserJourneyType.CX_SUPPORT_TOOL_FLOW, { singleton: true, controllerClass: CxSupportToolController } ) The journey is launched by SyncErrorServiceImpl when the sync engine's pending set enters a "capped" state. Telemetry is tagged under DesktopComponent.SYNC_ERRORS . Why the sync engine is capped: The user's Dropbox folder contains software development projects with node_modules , .git , and __pycache__ directories totaling approximately 965,000 files. These small, numerous files overwhelm the sync engine's pending set tracker, causing it to cap (a circuit-breaker mechanism). The capped state is then interpreted by SyncErrorServiceImpl as a sync error, which repeatedly launches the diagnostic journey. Storing development projects in cloud-sync folders is common. The sync engine should handle large file counts without surfacing internal diagnostics to users. Workaround Applied Set com.dropbox.ignored extended attribute on node_modules (17 dirs), .git (44 dirs), and __pycache__ (86 dirs) to exclude them from sync Patched app.asar to replace CxSupportToolController.launchJourney method body with return{result:0} (same byte length to preserve asar offsets), preventing the diagnostic window from spawning The asar patch is temporary - the auto-updater will overwrite it. Suggested Fixes Do not show raw engine debug info to end users. The CxSupportToolView displays PhaseInformation , SyncStatus , EngineWaitTracker , and PendingSetTracker output - this is engineering diagnostic data with no actionable information for customers. Add rate limiting or debounce to CxSupportToolController.launchJourney() . Currently, when SyncErrorServiceImpl detects a capped pending set, it can launch the journey repeatedly (every 2-12 seconds). Even if the diagnostic window is appropriate in some contexts, it should not spawn in an unbounded loop. Don't treat a capped pending set as a user-facing sync error. A large number of pending files is a normal condition for users with many small files (developers, photographers, etc.). The sync engine's circuit breaker should not trigger a customer-facing diagnostic journey - it should log internally and continue processing. Auto-ignore common regenerable directories. Directories like node_modules , .git , __pycache__ , venv , and build are well-known to be regenerable and contain large numbers of small files. These could be suggested for exclusion or ignored by default when detected, similar to how .gitignore patterns work. Bug 2: Chromium 102 Renderer FATAL Abort on macOS 26 Reproduction Steps Run Dropbox on macOS 26.3 Tahoe Observe stderr output (launch with ELECTRON_ENABLE_LOGGING=1 ) Renderer processes emit: FATAL:logging.cc(144) Failed to init logging: Operation not permitted Renderers abort immediately Main process logs: Error: Render frame was disposed before WebFrameMain could be accessed Root Cause Chromium 102 (used by Electron 19.1.9-dropbox.50) attempts to initialize file-based logging inside the renderer sandbox. macOS 26 tightened sandbox permissions, causing the logging.cc initialization fails with 'Operation not permitted'. Chromium treats this as a FATAL error, which calls abort() and kills the renderer process. The Electron project tracks similar issues with older Chromium on newer macOS (e.g., electron/electron#48311). Workaround Setting CHROME_LOG_FILE=/dev/null before launching Dropbox prevents the FATAL abort: CHROME_LOG_FILE=/dev/null /Applications/Dropbox.app/Contents/MacOS/Dropbox This sidesteps the permission failure by redirecting Chromium's log file. Suggested Fix Upgrade the Electron/Chromium runtime. Electron 19 (Chromium 102) is from June 2022 and EOL. Newer Chromium handles macOS sandbox changes fine. At the very least, logging.cc init should handle permission failures instead of calling abort() . Environment Details Component Value Dropbox version 243.3.6895 Electron 19.1.9-dropbox.50 Chromium 102 macOS 26.3 Tahoe Hardware MacBook Pro M4 Max, 36GB RAM Sync folder ~/Library/CloudStorage/Dropbox.nosync (~82 GB) Sync folder file count ~965,000 files (including node_modules/.git) Pending items at time of issue 600-900+, capped: true Diagnostic Artifacts I collected the following during the investigation and can provide any of it on request: Stderr logs from multiple launch configurations ( ELECTRON_ENABLE_LOGGING=1 , CHROME_LOG_FILE=/dev/null ) Extracted and annotated sections of main.js (module 898 - CxSupportToolController ) Extracted cxSupportToolView renderer and preload scripts apex.sqlite3 Stormcrow configuration (feature flag state) Screenshots of the CxSupportTool diagnostic window Process traces showing the renderer FATAL abort sequence Approaches That Did Not Resolve the Issue Approach Result Clean reinstall of Dropbox The CxSupportTool issue persisted Clearing GPU cache, Electron caches, and saved window state No effect ELECTRON_DISABLE_GPU=1 environment variable Delayed diagnostic window, but it didn't prevent it --disable-gpu , --disable-gpu-compositing CLI flags Crashed the entire application --no-sandbox CLI flag Crashed the entire application Clearing the Crashpad crash dump directory No effect --remote-debugging-port=9222 Dropbox strips the flag; no remote debug access Deleting Stormcrow feature flag database ( apex.sqlite3 ) No effect - rebuilt on next launch Deleting 59 conflicted copies from the sync folder Pending count actually increased temporarily Feel free to get in touch for any additional details or inquiries. Best regards, Ryan [personal information removed per the Community's Guidelines]
Every time I open my Dropbox folder the tray window pops open
Question or Issue I am using an HP laptop running windows 11 with the Dropbox app downloaded Recently, every time I open Dropbox, a box with my history pops up - SEE BELOW This is REALLY annoying, as I can't access my folders list which is hidden behind it. I have to keep tapping things until it disappears! How do I stop it appearing please?
I can't change the Dropbox web column headers
I was able to add Size header to my columns on Dropbox website last year sometime. But now when I go there to switch my List view column headers, I no longer get the inverted caret. However, I get it with Grid view and Large Grid view. Where did it go? It's the same in Safari as in Chrome. Application Affected Dropbox website Device MacBook Pro Operating System/Browser (if using the web) macOS Sequoia 15.7.4 Dropbox App Version (if using the app) NA
QuickLook is flickering on Mac OS
Integration Affected Finder Device MacBook Air, M3, 16GB RAM Operating System/Browser (if using the web) macOS Tahoe 26.2 Dropbox App Version (if using the app) 242.3.5699 Question or Issue I have been having the same issue as described in this thread for at least 1 month. It makes Quick Look (and therefore Finder) really awful to use. If you try to QuickLook or preview a pdf, image, etc. the quicklook state resets and refreshes. For example, I navigate in Finder to a pdf in my dropbox. I press SPACE to quicklook the item. I scroll down the PDF. The QuickLook resets/refreshes and I lose my place in the document. There is a huge impact on everyday tasks. Troubleshooting efforts: I viewed this topic and followed the suggestions there. It did not help. If I quit the Dropbox app, the issue persists. I found something really interesting. If I look at the Path Bar at the bottom of Finder, the folder icons keep changing several times per second (matching the flickering in QuickLook). Sometimes the icons in the Path Bar show as blank gray squares with dashed outlines or Green folders with check marks. It appears that these mini icons are constantly changing. If I disable the Path Bar, then the flickering stops in the quicklook. Again this happens in the Dropbox section of Finder, and not elsewhere. I've shown an example of the two options I see flicker on the Path Bar. Again the file previews and quicklooks flicker also, which is more problematic. I point out the Path Bar as a potentially useful piece of information to determine the problem. Thank you!
Feedback on the latest desktop version of Dropbox for Windows
Application Affected Dropbox Windows App (upgrade pushed 2/12/26) Device HP Envy x360, Lenovo IdeaPad5, Microsoft Surface Go 4 Operating System/Browser (if using the web) Windows 11 Dropbox App Version (if using the app) Version number no longer display in app! Question or Issue the new status window (right-click on icon) is too large. Looks nice, but too much white space, unnecessary icons that cannot be disabled. The window does not display properly on Surface Go 4 machine. Window does not position properly, and the bottom is cut off. The status window still has the long-standing issue with not closing properly when you click away from the window. The icon does not display properly in the tool bar (it is hidden) even when Dropbox is set not to hide. In other words, you reset the user's settings (Rude!) Overall, this is a fix where there wasn't a problem, creating new bugs that weren't there before. The new design is pretty, but puts form over function, ultimately making the app less useful.
File names are cut off on the Dropbox site
How is it possible for an app this old to still not allow a user to alter the field length? 20 odd characters is grossly insufficient for anyone with real organisation habits. Why can I not simply see longer file names? Why? What is the justification for this? Take myself, a 3d modeller. I constantly have files that are categorised by project/object/component (often with more additions like side or versions). It's maddening. We're nor working in 1024 resolutions anymore, we've all got second or third monitors. Screen real estate has never been higher. So why are we stuck with this archaic restriction? Every website I go to can adapt to window size but Dropbox is acting like it's still 2007. If this isn't fixed we're going to stop paying for it.
Dropbox menu bar icon for Mac OS was missing, here's how I solved it
Application Affected Dropbox Desktop App for Mac Device Macbook Pro (2020 13-inch M1 chip) Operating System Sequoia, MacOS15.37.2 Dropbox App Version 239.4.8301 Question or Issue Hi! I had been having the same issue it seems a bunch of other Mac users have been having: the Dropbox icon for the desktop app disappeared from my menu bar at the top of the screen months ago. The only way to access Dropbox after that (besides via browser) was to navigate to Finder, where I have an icon in the left Favorites list, or by going to Finder > Applications > Dropbox - HOWEVER, that would NOT open the app, but rather a Finder window that listed my Dropbox files. I finally got to the point today where I thought I'd Google to see if I could solve the issue, and quickly found so. many. support threads, both here and on the Mac support forum - but NONE of them were resolved (aside from a few folks who advised simply getting rid of some of the other icons in the menu bar to have the Dropbox one be revealed - but I tried that and it didn't work for me). ANYWAY, I DID FIGURE OUT - SOMEHOW - HOW TO RETURN THE DROPBOX ICON TO MY MENU BAR, so I thought I'd share: For me, all it took, was - INSTEAD of navigating to Dropbox via Finder - using Launchpad. I went to Launchpad, searched for the Dropbox app icon, and clicked on it to try to open the app. It didn't work - BUT! - it DID open the icon back up on my menu bar! And suddenly I have files listed as added "3 minutes ago" that are 4 years old... Hooray! I guess I hadn't actually been syncing all this time? Or who knows at this point. ANYWAY, I thought I'd share this miracle with all the other Mac users out there who were so frustrated at losing the icon in the menu bar :DCan I remove the "your activity" files?
It seem impossible to imagine but apparently Dropbox has decided that recent activity/files in recent activity are now permanently viewable until replaced by more recent activity. Really? I hope I'm wrong. Dropbox started out as uniquely user friendly and easy to use. I've watched that disappear over the years. It's becoming every bit the arrogant, controlling, short sighted and customer unfriendly type of site that it once stood out from. Again, if anyone has different information, please share. I'm truly hoping I'm wrong.
