Getting Cyberduck working again without a reinstall

The phrase covers at least four unrelated faults. The application will not launch. It launches but a bookmark never connects. It connects and then transfers fail partway. Or it works and the window behaves strangely, hides from Mission Control, or crashes on a specific folder. Each of these has a different first move, and the advice that circulates most widely, delete it and install it again, is the one that helps least, because the settings that would need clearing survive a reinstall untouched.

What follows is the order worth working in. Read the evidence the application is already writing, run the transcript if the problem is a connection, check the short list of documented incompatibilities, and only then consider moving versions. Most cases resolve before the last step.

Sort the symptom before touching anything

The four faults do not share a cause, so guessing wastes an afternoon. This table is the triage worth doing first.

Symptom	Most likely layer	First place to look
Will not launch, or quits immediately	The application or the OS	Crash report in DiagnosticReports
Launches, bookmark never connects	Network, credentials or server policy	Protocol transcript
Connects, listing is empty or wrong	Protocol or profile mismatch	Debug log, connection profile version
Transfers start then fail	Server limits or transfer settings	Debug log, transfer connection mode
Window or UI misbehaves	A known version bug or another app	Changelog, documented incompatibilities

The distinction between the second and third rows is the one people collapse most often. A bookmark that fails at the handshake and a bookmark that connects but shows nothing are entirely different problems, and treating a listing failure as a login failure leads to hours spent retyping a password that was never wrong.

Before any of that, one cheap check. Confirm the version in the About window against the current release, which at the time of writing is 9.5.4, dated 25 August 2026. A surprising share of reports are against builds from a year earlier, where the fix already shipped and simply never arrived because automatic updates were switched off in the preferences.

Read the log the application is already writing

Cyberduck writes a log whether or not anyone reads it. On macOS it lives at ~/Library/Logs/Cyberduck/cyberduck.log, and the preferences have a button that reveals it directly under Preferences and then Connection. Alongside the current file, compressed copies of the last five cycled logs sit in the same folder as cyberduck-*.log.zip, which matters when the failure happened yesterday and the file has since rolled over.

The same log is reachable through Console.app, in Applications and then Utilities, under Reports and then Log Reports. That route is useful when the Finder path is awkward to reach or when you want the live tail while reproducing the fault.

By default the log is not verbose. Turning on the setting called Enable debug log, in the same Connection section of the preferences, changes the amount of detail substantially. The correct sequence is to enable it, reproduce the failure once, and then read, rather than reading a log recorded before the setting was on.

If the application is crashing rather than complaining, the log is the wrong file. Crash reports go to ~/Library/Logs/DiagnosticReports/, named Cyberduck_*.crash on older systems and Cyberduck_*.ips on macOS 12 and later. The top of that file names the thread and the version, which is enough to search the project's issue tracker for an existing report before writing a new one.

Run the transcript when the problem is a connection

For anything that fails at connect time, the log is less useful than the transcript, which records the actual protocol requests and responses. It is not exposed in the interface. It comes out of a terminal:

log stream --predicate '(process == "Cyberduck") && (category == "transcript")' --level info

Leave that window open, then reproduce the connection in Cyberduck. The exchange appears as it happens. For HTTP based protocols such as WebDAV, S3 and the cloud storage backends, this is the only view that distinguishes a client fault from a server response, and the distinction usually ends the investigation immediately.

What to look for is which side gave up. A TLS negotiation that fails before any credential is sent is a cipher or certificate problem, not a password problem. A 403 after a successful authentication is a permissions issue on the server. A connection that opens and then stalls with no response is a firewall or a passive mode problem on FTP. None of these are fixed by reinstalling, and all of them are visible in the first twenty lines of the transcript.

Worth knowing before opening a ticket: the project asks explicitly that login and connection failures be taken up with the hosting provider first. That is not deflection. Servers disable ciphers, change ports and start requiring a second factor without announcing it, and the client is reporting the refusal accurately when it does.

The incompatibilities that are documented rather than rumoured

There is a short official list, and it is short enough to check in a minute. The project names three items it knows to interfere.

WindowDragon is listed as outright incompatible. If window management is installed and the browser window behaves oddly, that is the first thing to quit and retest, not a preference to hunt for.

Sophos Anti-Virus on-access scanning is named as well. On-access scanners sit between the application and the filesystem, and the symptom is usually slow or failing local writes during a download rather than an obvious error. Testing with scanning paused for a single transfer is a decisive check.

Browser Chooser 2 breaks OAuth. Cloud storage backends such as Google Drive, Dropbox, OneDrive and Box authenticate by opening a web browser, and an application that intercepts the browser handoff stops that flow completing. If cloud bookmarks fail while SFTP works, this is the shape of the fault.

Two further entries are worth knowing for SFTP specifically. Support for the Include, Match Host and Match User directives when reading an existing OpenSSH configuration was added in 9.5.0. On a Mac where ~/.ssh/config is organised with includes or match blocks, which is common once several hosts and jump hosts are involved, an older build simply did not see part of the configuration, and the resulting failure looks like a wrong key rather than an unread setting.

To this the changelog adds a set of concrete bugs fixed recently, which is worth scanning because the symptoms are memorable. A crash when opening the bookmark window was fixed in 9.5.3. A crash opening a folder whose name starts with a dot was fixed in 9.5.2, as was an attempt to change to the working directory of a previous connection when connecting to a new bookmark. Connection profiles not updating to the latest available version was fixed in the same release. The browser window failing to appear in Exposé and Mission Control was fixed in 9.5.0. If any of those descriptions matches what is happening, the fix is an update, not a diagnosis.

When the fault is the registration key rather than the application

A particular case gets misfiled as the application being broken. A registration key that will not register is almost always a file that was damaged in transit rather than an invalid key.

The key arrives by email as an attachment whose filename ends in .cyberducklicense. The project documents that some email applications rewrite the extension to .xml when saving the attachment, and that a file modified this way will not register. The remedies it suggests are to fetch the attachment through a different browser or mail client, or to forward the message to another mail account and download it from there. Keys can also be recovered later using the email address given at the time of the donation, so a lost attachment is not a lost key.

This is worth separating out because none of the debugging above applies to it, and because support for key problems goes to a dedicated address rather than the public tracker.

Moving versions, in both directions

Two moves are available and they are not symmetrical.

Moving forward is the obvious one. The update feed is switchable in the preferences, under Update, so a fix that has landed in a snapshot or beta build can be picked up before it reaches a stable release. Snapshot builds are published regularly and are not tested, which is an acceptable trade for a machine that is already broken and an unacceptable one for a machine that is not.

Moving backward is the move people forget exists. Installers for previous versions stay published in the project changelog, so a release that broke a workflow can be rolled back the same afternoon. This is the right response when the failure started immediately after an update and the changelog shows a change in the area concerned. It is the wrong response when the failure has been growing gradually, which points at a server or a certificate rather than the client.

Before either move, the version floor is worth confirming. Current builds require macOS 10.13 or later on 64 bit Intel or Apple silicon. On an older system the changelog also documents which earlier release is the last one that runs there, which is the only supported path on a Mac that cannot be upgraded.

Why reinstalling usually changes nothing

The reason a reinstall disappoints is that it does not clear anything that matters. Dragging the application to the trash leaves the preferences at ~/Library/Preferences/ch.sudo.cyberduck.plist and leaves the whole application support tree, bookmarks and history and installed connection profiles included, inside ~/Library/Group Containers/G69SCX94XU.duck/. A fresh copy starts up and reads exactly the same state that was there before.

If the intent really is to start clean, that container is the thing to move aside, and it should be moved rather than deleted, because it is shared with Cyberduck CLI and Mountain Duck. Renaming it, launching once to confirm the fault is gone, and then restoring it if it is not, gives a clean answer without losing bookmarks.

There is also a cheaper version of the same test. A single new bookmark, created from scratch against the same server, isolates a corrupt bookmark from a broken application in about thirty seconds, and it is the test worth running before anything is moved at all.

What to change first

Turn on the debug log, reproduce the fault once, and read the last thirty lines. If the fault is a connection, run the transcript command in a terminal and watch which side stops talking. Those two steps identify the layer in nearly every case, and a reinstall belongs after them, not before.

If the conclusion is that the client is fine and the friction is having a transfer window, a Finder window and a terminal all open to do one job, that is a different problem from a broken application, and a file manager that keeps those in one place is the thing to look at, with Atriens among the candidates.