Sloth: a macOS GUI for lsof that shows every open file, socket and pipe

The problem Sloth solves for Mac users who keep reaching for lsof

lsof answers a narrow but frequent question: which process has this file, port or device open. On macOS the tool is present and fast, but its output is a flat table with cryptic columns, and filtering it means recalling flags. Sloth takes the same data and puts it in a sortable, searchable outline view. The README describes it as "a friendly, exploratory graphical user interface built on top of the lsof command line tool", and that framing is accurate: the app is a parser and a viewer, not a replacement for the underlying utility.

The audience is Mac users doing local diagnosis. A developer wondering which process holds a port, a sysadmin checking what a daemon has open, or anyone curious why a volume will not eject. The README lists the categories it exposes: open files, directories, IP sockets, devices, Unix domain sockets and pipes. It also states that it can show sockets and pipes established between processes, which is the part of lsof output that is hardest to read by hand.

It is not a monitoring tool. There is no history, no alerting and no daemon. You open it, look at a snapshot, and close it.

How Sloth turns lsof output into an outline view

The mechanism is stated plainly in the README: the output of lsof is parsed and shown in a sortable, searchable outline view. Everything else in the app is built around that parsed model. Because the data comes from lsof rather than from a private kernel interface, what Sloth shows is bounded by what lsof itself reports on the running macOS version.

The filtering and sorting features map onto the columns lsof produces. The README says you can filter by name, access mode, volume, type, location, or using regular expressions, and sort by process name, file count, type, process ID, user ID, Carbon PSN or bundle UTI. That last group is macOS-specific: Carbon PSN and bundle UTI are not things lsof prints, so the app is enriching the parsed rows with information about the owning application. The same applies to the inspection window, which the README describes as showing detailed macOS and Unix file, socket and process info.

Privileges are the other half of the data flow. lsof run as an ordinary user sees only what that user may see. Sloth offers in-app authentication to scan with root privileges, which is the difference between a partial view and a complete one. The README does not describe how that authentication is implemented, only that it exists.

Installing Sloth on macOS and running a first scan

The README offers two installation paths. The first is a direct download of Sloth 3.6, described as roughly 1.3 MB, Universal ARM/Intel 64-bit, requiring macOS 11 or later, and Developer ID signed and notarized. The second is Homebrew, with the caveat that the cask "may not be the latest version":

brew install --cask sloth

After that command completes, the app appears in your Applications folder and can be launched from there or with open -a Sloth. If you are on an older macOS release, the README gives version guidance: version 3.4 for macOS 10.13 to 10.15, and version 3.2 for 10.9 to 10.12, with older builds available from the project's download page.

Once the app is running, the first useful action is to authenticate so the scan can run with root privileges, then sort by file count to find the processes holding the most open handles. From there the contextual menu is where the file operations live; the README calls it a "powerful contextual menu" but does not enumerate its entries.

If you prefer to build from source, the repository root contains a Makefile and the README gives one command:

make build_unsigned

The Makefile sets the build directory to products, so the resulting bundle is written to products/Sloth.app. Building requires Xcode build tools. A signed variant, make build_signed, also exists in the Makefile, along with make archives for producing the zip files.

Where Sloth stops being the right tool

The clearest limitation is the platform. Sloth is a native Mac app written in Objective-C and Cocoa, and the README makes no claim of portability. On Linux or Windows, lsof or its equivalents are still available, but this front end is not.

A second limitation is that the app inherits lsof's blind spots. It parses lsof output, so anything lsof cannot see, Sloth cannot show. The README does not discuss cases where lsof reports incomplete data, and it does not describe any fallback source.

The third is automation. Sloth is a GUI with no documented command-line interface, no export format and no scripting hook in the README. If you need to log open files over time, diff two snapshots or feed the result into another program, you should stay with lsof and its flags. The app is for looking, not for piping.

Finally, the privilege model is a real constraint. Without authenticating, the scan is limited to what your user account can inspect, which on a busy Mac leaves gaps around system daemons. The README states that in-app authentication exists for root-privileged scanning but says nothing about how credentials are handled, so that is worth understanding before you use it on a shared or managed machine.

Sloth against lsof itself, and against Activity Monitor

The honest alternative to Sloth is lsof. The difference is not in the data, since Sloth reads lsof's output, but in the interaction model. lsof gives you flags and text you can pipe; Sloth gives you columns you can click. If your question is "what is holding port 8080", lsof -i :8080 answers it in one line and you are done. If your question is "what does this process have open, and how does that compare with the process next to it", the outline view and the sort controls are faster than composing filter expressions.

Activity Monitor is the other comparison a Mac user will make. It is the system's own process viewer, and it shows CPU, memory, energy and network activity. It does not present a per-process list of open files, directories, devices, Unix domain sockets and pipes, which is exactly the surface Sloth covers. The two overlap on process identity and not much else.

A third option is to write your own parser around lsof. That is what Sloth is, and the README's own description concedes the point. Unless you need a different presentation or a different set of filters, there is little reason to rebuild it.

Licence, maintenance and what an upgrade costs you

Sloth is distributed under the BSD 3-Clause licence, and the README carries the full text with a copyright line covering 2004 to 2026. The practical implications: you may redistribute source and binary forms provided the copyright notice and disclaimer are retained, and you may not use the copyright holder's name or contributors' names to endorse derived products without written permission. That third clause is the one that catches people building branded forks. This is a description of the licence text, not legal advice.

The repository is not archived, and the last push was on 2026-08-30. Releases are spaced out rather than continuous: 3.4 on 2025-05-19, 3.5 on 2025-11-15, and 3.6 on 2026-04-22. The README notes the project has been developed since 2004, which is consistent with that cadence. Upgrades are ordinary macOS app updates, and the Homebrew cask is the low-effort path, with the caveat that the README itself warns the cask may lag the latest release.

The cost that matters is not the upgrade, it is the version floor. macOS 11 or later for 3.6, 10.13 to 10.15 for 3.4, 10.9 to 10.12 for 3.2. If you support a fleet across those boundaries, you are maintaining more than one version. Building from source adds an Xcode dependency, and the Makefile's release target also invokes Sparkle signing tooling under the sparkle directory, so a full signed release is more involved than make build_unsigned.

Editorial conclusion

Adopt Sloth if you are on macOS 11 or later and want to inspect open files, sockets or pipes without reading lsof output line by line. Skip it on Linux, Windows or in a headless SSH session, and skip it if you need scripted, machine-readable output, because the app is a GUI and the README documents no CLI mode. Before relying on it for a diagnosis, verify that the app can obtain root privileges through its in-app authentication, since without that it can only show what your user account is permitted to see.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. Project website
3. README
4. Releases
5. sveinbjornt/Sloth on GitHub