Uninstall & Clean Reinstall
Removing Swarmfile from a machine is straightforward, with one important distinction: repairing an install and removing one are different operations, and repair is almost always what you want. If the app is misbehaving - a broken mount, a missing CLI tool, a half-applied update - use Diagnostics → Reinstall… or swarmfile-doctor --repair --yes instead. A repair reinstalls the full package and keeps your cache, queued uploads, config, and sign-in; removing the app and its data does not. A repair stops the engine briefly while the installer runs (on Windows the drive is detached cleanly first) and it reconnects when the install finishes; queued work is unaffected.
Everything below is for a deliberate removal - decommissioning a laptop, handing it to someone else, or a truly clean slate.
Before you remove anything#
Three things live only on this machine and are lost when you delete its data:
- Queued uploads. Saves that haven't reached the hub yet live in the local database. Check
swarmfile status(thepending uploads/commits pendingcounters) andswarmfile uploads --wait; wait for zero, or accept losing those changes. - Stuck saves.
swarmfile sync stucklists saves the hub keeps refusing. Export or resolve them before wiping the cache - they will not come back. - Reservations and locks.
swarmfile offline returnreleases any Pack & Go reservations this machine holds; checkout locks you took expire on their own lease, but releasing them now is neighborly. If this machine runs a seed node, disable seed mode first (swarmfile seed disable) so the org's discovery list doesn't keep advertising it.
Anything staged in a changelist that has been parked is kept on the hub and can be resumed from another machine; unsent changelist work is local and goes with the cache.
One more piece of wiring is separate from the app install: if this machine used a project as a git-LFS server, run swarmfile-lfs uninstall to remove the custom-transfer adapter from your git configuration. Uninstalling the app does not do that for you.
Windows#
- Quit the Desktop App from the tray (including any "quit engine" option so the mount dismounts). The uninstaller stops the engine and tray itself (with a force-kill backstop), but quitting first avoids holding the mount open.
- Uninstall from Settings → Apps → Swarmfile → Uninstall. For scripted removal, find the product code and call
msiexec(the CI harness does the same):
If the install came from the bundled$key = Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall', 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall' | Where-Object { $_.GetValue('DisplayName') -match 'Swarmfile' } | Select-Object -First 1 msiexec /x $key.PSChildName /qn /norestartSetup.exe, its uninstaller lives inProgramData\Package Cache; Settings → Apps invokes it with/uninstallfor you. - The uninstaller removes the program files (
C:\Program Files\Swarmfile), thePATHentry, theswarmfile://protocol registration, the inbound UDP firewall rules, the Explorer overlay handlers, the Start Menu shortcut, the per-machineRunentries, and the Swarmfile Updater scheduled task. WinFsp, the VC++ Redistributable, and WebView2 are chain prerequisites and deliberately stay installed. - Per-user data is deliberately left behind (uninstalling for one user shouldn't wipe another's cache):
This removes the cache, queued uploads, config, and sign-in for that user only. One leftover is harmless:Remove-Item -Recurse -Force "$env:LOCALAPPDATA\swarmfile"HKCU\Software\Swarmfile\MountPoint(the remembered drive letter), which the MSI doesn't own.
To reinstall, run the bundled Setup.exe again - or a repair if you only wanted the app fixed.
macOS#
The .pkg install is machine-wide: the app in /Applications, LaunchAgents in /Library/LaunchAgents, and CLI symlinks in /usr/local/bin. Removing it takes a few commands; run the launchctl lines as the logged-in user and the rm lines with sudo.
- Quit the Desktop App, then stop its background services:
(A staging install uses a namespaced label - checklaunchctl bootout gui/$UID/dev.swarmfile.tray 2>/dev/null launchctl bootout gui/$UID/dev.swarmfile.engine 2>/dev/nulllaunchctl list | grep swarmfilefor the exact names.) - Remove the app, the agents, the CLI links, and the bundled FUSE-T pieces:
sudo rm -rf /Applications/Swarmfile.app sudo rm -f /Library/LaunchAgents/dev.swarmfile.engine.plist \ /Library/LaunchAgents/dev.swarmfile.tray.plist sudo rm -f /usr/local/bin/swarmfile /usr/local/bin/swarmfile-* /usr/local/bin/go-nfsv4 sudo rm -f /usr/local/lib/libfuse3.4.dylib /usr/local/lib/libfuse3.dylib \ /usr/local/lib/libfuse-t-1.2.7.dylib /usr/local/lib/libfuse-t.dylib sudo rm -rf "/Library/Application Support/fuse-t" sudo pkgutil --forget dev.swarmfile - Remove the per-user data (cache, queue, config, token):
The engine's cache and config are therm -rf ~/Library/Caches/swarmfile ~/.cache/swarmfile ~/.config/swarmfile~/.cache/swarmfile/~/.config/swarmfilepair;~/Library/Caches/swarmfilecovers.dmg/legacy layouts. Repeat per user profile.
If Finder or an app still shows the drive, it is a stale mount from a killed helper - log out and back in, or reboot, before wiping. swarmfile-doctor --repair --yes is the supported way to fix an install you intend to keep.
Linux#
- Quit the Desktop App and the engine for each logged-in user first - the package's pre-remove script disables the systemd units but does not stop services already running in your session, so a removed engine can keep serving its mount until you log out or kill it.
- Remove the package:
Removal disables the per-usersudo apt remove swarmfile # remove the app and units sudo apt purge swarmfile # also remove the packaged /etc/swarmfileswarmfile-engineandswarmfile-traysystemd units; nothing else (firewall, mounts) is touched. If a mount is still present after removal, unmount it (fusermount -u <mount point>) or log out. - Remove the per-user data for each user who signed in:
That covers the cache, queue, config, and token. If you ran a seed or a headless engine with its ownrm -rf ~/.cache/swarmfile ~/.config/swarmfileSWARMFILE_CACHE_DIR, remove that directory too.
What lives where#
| Platform | Application | Per-user data (cache, queue, config, token) |
|---|---|---|
| Windows | C:\Program Files\Swarmfile | %LOCALAPPDATA%\swarmfile |
| macOS | /Applications/Swarmfile.app, /Library/LaunchAgents, /usr/local/bin, /usr/local/lib/libfuse*, /Library/Application Support/fuse-t | ~/.cache/swarmfile (cache, queue, logs) + ~/.config/swarmfile (config) |
| Linux | package files, per-user systemd units | ~/.cache/swarmfile + ~/.config/swarmfile; /etc/swarmfile (purge only) |
The cache directory is also where log files live, so if you're removing the machine as part of a support case, copy that directory aside first.
Clean reinstall#
To start completely fresh on the same machine:
- Follow the uninstall steps above, including deleting the per-user data.
- Install the current package from swarmfile.com/download - or, on macOS, make sure it's the
.pkg: the.dmgdoesn't set up the engine service or the CLI onPATH. - Sign in again and re-open the project. The mount comes back where the Drive Letter / mount-point settings say; nothing on the hub is affected by the reinstall.
Where to go next#
- Release Channels & Updates - how updates work and what a repair does.
- Supported Platforms & System Requirements - installer names and per-platform layout.
- Deploying to Your Team - removing or re-provisioning machines at fleet scale.