What stays on disk after Cyberduck is gone

Dragging Cyberduck to the trash removes about a quarter of it. Bookmarks, history, installed connection profiles, preferences, logs, crash reports and saved passwords all live outside the application bundle and all survive. That is deliberate, not sloppiness, and it is why reinstalling to fix a problem so rarely changes anything.

It also means the removal has two versions with different consequences. One frees the disk space and leaves everything ready for a reinstall. The other genuinely clears the state, and it has a trap in it, because one of the folders involved is shared with two other applications from the same developer. Working out which removal is wanted comes before deleting anything.

The official steps, and what they cover

The project documents three steps for macOS.

Close the application, open the Applications folder with the keyboard shortcut for it, select Cyberduck.app and move it to the trash. Then, inside ~/Library/, find the Group Containers folder and delete the folder named G69SCX94XU.duck. Optionally, delete the saved login credentials in Keychain Access.

That sequence is correct as far as it goes, and it is more than most vendors document. What it does not do is name every file the application wrote, and the gap includes at least one path that matters.

Note the order in those steps. Closing the application first is not a formality. Preferences and bookmarks are written on quit, so deleting state under a running copy means some of it reappears when that copy exits. Quit first, then delete.

Every path, and what it holds

Path	What is in it	Removed by official steps
/Applications/Cyberduck.app	The application itself	Yes
~/Library/Group Containers/G69SCX94XU.duck/	Bookmarks, history, connection profiles	Yes
~/Library/Preferences/ch.sudo.cyberduck.plist	Preferences	No
~/Library/Logs/Cyberduck/	Current log and five rotated archives	No
~/Library/Logs/DiagnosticReports/Cyberduck_*	Crash reports	No
Keychain Access entries	Server passwords as internet passwords	Only if done manually

The preferences file is the notable omission. Every setting configured over the life of the installation, the transfer connection mode, the bandwidth limit, the default protocol, the download folder, the update feed, sits in ch.sudo.cyberduck.plist. The project documents this location in its own help, under preferences and application support file locations, but it is not in the uninstall list.

The practical result is that a reinstall after following the official steps arrives with fresh bookmarks and the old preferences. For anyone uninstalling because a setting is suspected of causing trouble, that is exactly the wrong half to keep.

Logs are harmless but not always small. The folder holds the current cyberduck.log plus compressed copies of the last five rotated logs as cyberduck-*.log.zip. On a machine where debug logging was left enabled, those archives can be worth reclaiming.

The shared folder, and why deleting it can surprise you

This is the part worth slowing down for. The Group Containers folder is not Cyberduck's alone.

The application support directory inside it, at ~/Library/Group Containers/G69SCX94XU.duck/Library/Application Support/duck/, holds bookmarks, history and connection profiles, and the project states directly that these settings are shared with Cyberduck CLI and Mountain Duck. One store, three clients.

So deleting G69SCX94XU.duck while Mountain Duck is still installed removes Mountain Duck's bookmarks too. The same applies to any scripted use of the duck command line tool, which will find its connection profiles gone. Neither application is uninstalled by this, and neither will say anything useful about why its bookmarks vanished. It simply starts empty.

The safe sequence is to check first whether either of the other two is present, and if so, to export what is needed before deleting. Bookmarks in that folder are individual .duck files and can be copied out as ordinary files. Copying the folder somewhere else before deleting the original costs a few seconds and makes the whole operation reversible.

If Cyberduck is the only one of the three installed, the official step is safe as written and no precaution is needed.

Getting the bookmarks out before they go

If there is any chance of needing those servers again, the ten minutes spent preserving them is worth more than the disk space being reclaimed.

Bookmarks are stored as individual files with a .duck extension inside that shared folder, which makes them ordinary objects to copy rather than something locked inside a database. Copying the whole application support directory to another location preserves bookmarks, the history of visited servers with their timestamps, and the set of connection profiles that were installed.

Connection profiles are the part most likely to be missed. They are installed selectively, by ticking entries in the preferences under Profiles, and the list covers a long tail of hosting providers and storage services. An installation that has been in use for years often has a handful enabled that took some finding. They come back, but only if someone remembers which ones they were, and a copy of the folder answers that question later without any remembering.

It is also worth noting what the bookmarks contain and what they do not. Hostnames, paths, protocols and usernames travel with the .duck file. Passwords do not, because they are in the Keychain. Carrying bookmarks to a new machine therefore moves the configuration but not the credentials, which is the correct behaviour and also the reason a restored set of bookmarks prompts for every password on first use.

What the application registered with the system

Beyond the folders, an installation leaves a few registrations behind, and they explain some odd behaviour after a removal.

Cyberduck can be set as the system wide handler for FTP and SFTP links, which means clicking such a link in a browser or an email opens it. Once the application is gone, those links have no handler and either do nothing or produce an unhelpful message. Nothing needs cleaning up for this, but if FTP links stop working after an uninstall, this is why, and the fix is to install something else that claims the protocol.

The application also opens .inetloc and .duck bookmark files from the Finder. Any of those files saved into a project folder or on the Desktop remains on disk after the removal and becomes an icon that no longer opens anything. They are safe to keep and trivially small, and worth keeping if the servers might be needed again, since they are the bookmark in portable form.

A Spotlight importer indexes bookmark files so that a server can be found from the system search field. That index entry disappears along with the files it pointed at, which is the expected result rather than a leftover.

Finally, if debug logging was ever enabled, the logs folder has been accumulating rotated archives the whole time. Checking its size before deciding whether to bother is reasonable. On a machine used heavily for transfers it can be the largest single thing the uninstall recovers, and on a lightly used one it is a rounding error.

Keychain entries are a separate decision

Server passwords do not live in any of the folders above. They are stored in the system Keychain as internet passwords, which is why they survive every kind of removal and why the official steps list clearing them as optional rather than necessary.

Optional is the right word, and the reason is worth understanding. Because they are stored as standard internet passwords rather than in a private format, other applications on the machine can use the same entries. A password saved while connecting to a server through Cyberduck may be the same entry another client, a script, or a mounted volume relies on. Deleting the lot in one pass to be thorough can break something unrelated.

The considered approach is to open Keychain Access, search for the hostnames concerned, and remove only the entries actually wanted gone. If the machine is being handed to someone else, clearing them is clearly correct. If Cyberduck is simply being replaced, leaving them alone is usually the better call.

Two removals, two sequences

For freeing disk space or replacing the application while keeping the setup, do only the first official step. Move the application to the trash and stop there. Bookmarks, profiles and preferences stay intact, and a reinstall later picks up exactly where things left off.

For genuinely clearing the state, whether to hand over the machine or to rule out a corrupt configuration, the full list is the application bundle, the Group Containers folder, the preferences plist, the logs folder, and the crash reports. Check for Mountain Duck and Cyberduck CLI before the second of those.

There is a third case that gets mislabelled as uninstalling. When the goal is to test whether a setting is causing a fault, nothing needs deleting at all. Renaming the Group Containers folder and the preferences plist, launching once, and then restoring them if the fault persists answers the question without losing anything. That test is faster than a reinstall and, unlike a reinstall, it actually changes the state being tested.

One thing worth keeping regardless of which path is taken. If a registration key was ever purchased, the .cyberducklicense file is worth archiving somewhere outside all of these folders. Keys can be recovered later using the email address used at the time of the donation, but having the file to hand is simpler than requesting it again.

What the removal usually says about the workflow

People uninstall a transfer client for one of three reasons, and they lead to different places.

Some have stopped needing remote transfers on that machine, in which case the full removal is the end of it. Some want the remote storage to behave like a local disk rather than something to move files in and out of, which is the Mountain Duck case and the reason to check the shared folder before deleting it. And some have realised the transfer client was never the bottleneck.

That third group is the largest. The friction was having a transfer window, a Finder window and a terminal open all session, keeping three navigation states aligned by hand. Removing one of the three does not reduce the switching, it just removes a capability. What reduces it is consolidating the local side, which is a file manager question rather than a transfer client question.

What to change first

Decide which removal is wanted before opening the Library folder. If it is disk space, move the application to the trash and stop. If it is a clean slate, work down the table above, and check for Mountain Duck and Cyberduck CLI before deleting the shared folder.

If the reason for uninstalling is that three windows were needed to do one job, the replacement to look at is a file manager with a built-in terminal rather than another transfer client, and Atriens is one of those.