# muCommander: a dual pane file manager that runs anywhere a JVM does

> muCommander is a lightweight file manager with a two pane interface, written in Java so that the same build runs on macOS, Windows, Linux, the BSDs and Solaris, and it is built as a set of Gradle subprojects with a plug-in module per archive format and per remote protocol. It suits someone who wants the same file manager everywhere, and it asks for a JVM, which is the price of that portability.

**mucommander/mucommander** — A lightweight, cross-platform file manager with a dual-pane interface

- Repository: https://github.com/mucommander/mucommander
- Website: https://www.mucommander.com
- Stars: 1,296 · Forks: 212
- Language: Java
- License: NOASSERTION
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/mucommander-mucommander

## What muCommander is

muCommander is a lightweight, cross-platform file manager with a dual-pane interface, and it runs on any operating system with Java support, with macOS, Windows, Linux, the BSDs and Solaris named in the README.

The dual-pane layout is the classic one, two file listings side by side, and the appeal of that layout is that moving a file is a drag between two places you are already looking at rather than a copy, paste and navigate sequence.

What makes muCommander different from the file managers that ship with those operating systems is the consistency. The same application, the same interface, the same keyboard handling on a machine in a data centre and on a laptop, which matters for anyone who administers several systems or works across a mixed estate.

The price of that consistency is the runtime. Every launch pays for the JVM, and the application cannot be as instantly responsive as a native file manager. For a tool you keep open all day while moving files around, that is a reasonable trade. For a tool you open once a minute to find a file, it is not.

The project is GPL licensed, and the version badge in the README reads 1.6.3. The last push to the repository was on 2026-10-15, and the release list shows a nightly build published on the same day alongside numbered releases 1.6.2-1 from May 2026 and 1.6.1-1 from April 2026. The project also has a Coverity Scan badge, a GitHub Discussions space and a translator's wiki page, so it is maintained with the usual static analysis and community infrastructure.

## Running it from source with the Gradle wrapper

The development prerequisites are short, which is one of the pleasant things about a Java project that has been around for a while.

You need a Java Development Kit, version 11 or later, and Git. The code repository is made of a main project with the core functionality and several sub-projects, and these are Gradle projects. The documentation notes that most popular IDEs import Gradle projects out of the box or through a plugin, and that importing the main project at the root of the repository gives you all the required code in the IDE.

The Gradle wrapper handles the command line build, and the commands work from the root directory with no further installation.

```bash
./gradlew run
```

There is a second form to know about, and the documentation gives a reason for it.

```bash
./gradlew clean run
```

That is the one to use when you hit an unclear compilation error, or when you want to be sure you are running the code you have just modified rather than something the incremental build kept around. You can also run it from inside the IDE by executing the run task of the wrapper.

The build layout in the repository root supports this, with a build.gradle, a build_template.properties that holds the version and packaging properties, the wrapper scripts for both Unix and Windows, and a gradle directory.

## Debugging through the same wrapper

Debugging is configured through Gradle properties rather than through an IDE run configuration, and the documentation is explicit about both switches.

To debug muCommander you add the debug property with a port number while running it, and to control whether the JVM suspends at startup you use the suspend parameter, where suspend=y is the default.

```bash
./gradlew run -Pdebug=5005 -Psuspend=n
```

That is a good default, by the way. A debug port that suspends the JVM until a debugger attaches is what you want when the code does something at startup that you need to catch, and a debug port that does not suspend is what you want when you just want to break somewhere later.

The documentation then tells you to connect a debugger to that port with your favourite IDE, and links an example of doing it with IntelliJ.

Setting this up through the build rather than through the IDE is a deliberate choice, and it has a practical benefit: the same command works from a terminal, from a script and from a continuous integration job, and every developer on the project ends up debugging the same way. The downside is that the remote debugging setup in your IDE has to be pointed at a port and a suspend flag rather than at a run configuration, which is a small amount of friction the first time you do it.

## Packaging for five platforms, and the macOS quarantine problem

The packaging section lists one Gradle task per platform, which tells you how seriously the project takes shipping on operating systems other than the developer's own.

The macOS disk image is produced by a clean and dmg task, with a flag to skip signing and a flag for the architecture, either x86_64 or aarch64.

```bash
./gradlew clean dmg -PskipDmgSign -Parch=[x86_64|aarch64]
```

Because the application is not signed, the documentation warns that macOS may refuse to start it with the message that muCommander is damaged and cannot be opened, and gives the fix, removing the quarantine attribute recursively.

```bash
sudo xattr -r -d com.apple.quarantine /Applications/muCommander.app
```

That is the kind of note that only appears in a project where someone has actually built and installed the thing on a Mac. The quarantine attribute is what Gatekeeper sets on a downloaded file, and an unsigned application trips it, so the fix is to tell the system that you know the file is there.

For the other platforms there is a task each, an exe for Windows produced with launch4j, a tgz for Linux and Unix, an rpm for Red Hat flavours and a deb for Debian flavours.

```bash
./gradlew clean createExe
./gradlew clean tgz
./gradlew clean rpm
./gradlew clean deb
```

A project that ships a Windows installer built by launch4j alongside native Linux packages is one that treats distribution as part of the product, and the wiki has a page with more packaging options.

## The module layout: one subproject per format and per protocol

The repository root is a list of subprojects, and the names describe the architecture more clearly than any documentation would.

There is mucommander-core with the bulk of the application, and a family of mucommander-commons modules for the shared pieces, with separate ones for collections, configuration, file handling, input and output, the runtime, and general utilities. There is mucommander-preferences, mucommander-process, mucommander-command, mucommander-encoding, mucommander-archiver and mucommander-bonjour for network discovery.

The format modules are the interesting set, because there is one per archive type: ar, bzip2, cpio, gzip, iso, libguestfs, lst, rar, rpm, sevenzip, tar, xz and zip, each in its own mucommander-format- project, with mucommander-archiver alongside them for the archive handling side. The protocol modules follow the same pattern, with a mucommander-protocol- project per remote source, among them adb, dropbox, ftp, gcs, gdrive, hadoop and http.

That structure is the design statement. A file manager that can read a dozen archive formats and talk to a dozen remote services will get slow and fragile if all of that is one compilation unit, and splitting it into modules means the optional parts can be maintained, and in principle loaded, independently.

The platform layer is split the same way, with mucommander-os-api as the abstraction and separate implementations for Linux, macOS, macOS on Java 8, OpenVMS and Windows, plus a core preload module.

There are also vendored and borrowed pieces in the tree, with directories for a bzip2 implementation, a JSON library, a Kotlin reflection library, a bundled JRE, third party libraries, and the terminal emulator library the project uses, which comes from the JetBrains editor. And the README carries a Powered by badge crediting JetBrains Open Source Support.

## Contributing, and the state of the project

The contribution section describes three ways in, and the third is the one that is unusual.

The first two are standard. File an issue if you found a bug or thought of a missing feature, and if you want to fix a bug or implement a feature, fork the repository and submit a pull request using the standard GitHub flow, with changes merged to the master branch.

The third is translation. If you happen to speak a language that muCommander is not available in, or that you are able to improve existing translations in, you can help translate the interface, with the details on a wiki page.

That is worth noting because a file manager is an interface, and an interface that is not translated is usable by fewer people than the code would otherwise support. It is also the kind of contribution that has no pull request attached, and a project that has a documented path for it has probably had translators before.

GitHub Discussions is offered for questions and for the general conversation.

On the state of the project, the release list is the clearest signal. There is a nightly build published on the same day as the last push, and the two numbered releases before it are 1.6.2-1 and 1.6.1-1, both in 2026. The version badge reads 1.6.3, which is the version the nightly is building towards.

The build badge points at a nightly workflow, the Coverity badge is present for static analysis, and there is a CodeRabbit configuration in the repository root, which suggests automated review is in use for pull requests. Between the nightly builds, the coverage of the platform matrix, and the presence of a translator's guide, this is a project that is still actively maintained rather than merely still running.

## Conclusion

Adopt muCommander if you move between operating systems and want one file manager with the same shortcuts and the same interface everywhere, because that consistency is the whole argument for a JVM implementation. Do not adopt it if startup time matters, since a Java application pays for the runtime on every launch. Before you build from source, read the packaging section, because the macOS disk image needs a quarantine attribute removed by hand when it is unsigned, and the project ships a nightly build tag as well as numbered releases.

## FAQ

### What is muCommander?

It is a lightweight, cross-platform file manager with a dual-pane interface, written in Java so that it runs on any operating system with Java support, including macOS, Windows, Linux, the BSDs and Solaris. The project is GPL licensed.

### How do I build and run muCommander from source?

You need a JDK of version 11 or later and Git, then run ./gradlew run from the root of the repository, where the Gradle wrapper handles the build with no further installation. The documentation recommends ./gradlew clean run when you hit an unclear compilation error or want to be sure you are running the code you just changed.

### How do I debug muCommander?

Add the debug property with a port number when running it, and use the suspend parameter to control whether the JVM waits for the debugger, with suspend=y as the default. The example is ./gradlew run -Pdebug=5005 -Psuspend=n, after which you connect a debugger from your IDE to that port.

### What packages does muCommander ship?

A disk image for macOS with a flag to skip signing and a choice of x86_64 or aarch64, an exe for Windows built with launch4j, a tgz for Linux and Unix, an rpm for Red Hat flavours and a deb for Debian flavours, with more options described in the packaging wiki page.

## Sources

- [Issues](https://github.com/mucommander/mucommander/issues)
- [mucommander/mucommander on GitHub](https://github.com/mucommander/mucommander)
- [Project website](https://www.mucommander.com)
- [README](https://github.com/mucommander/mucommander/blob/master/README.md)
- [Releases](https://github.com/mucommander/mucommander/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mucommander-mucommander