Sigma File Manager: a Tauri-based explorer for Windows and Linux

What problem Sigma File Manager solves, and for whom

The default file manager on Windows ships with the operating system, so most people never evaluate an alternative. Sigma File Manager exists for the people who do: users who keep several directories open at once, move files between two locations constantly, and want to reach a file by typing its name rather than clicking through a tree. The README describes it as a "free, open-source, quickly evolving, modern file manager (explorer / finder) app for Windows and Linux." That phrase sets the boundary. Windows and Linux are the targets; the README says macOS is supported but builds are not provided. The repository is a TypeScript project at version 2.2.0, published under the name sigma-file-manager, and the top-level layout contains both a src/ directory and a src-tauri/ directory, which matches the Tauri desktop shell the README and the package scripts assume.

The feature list is long, but three items define the intended audience. Tabs keep multiple directories open. Split view divides any tab into two panes that navigate independently, so a transfer is a drag between panes instead of a window shuffle. Smart global search claims to find files and folders in seconds, with a typo correction system that handles wrong case, wrong word order, missing words and missing file extensions. Everything else in the README, from tags and zip archives to the home banner and visual effects, is customization around those three. If you are content with a single window and the system search, this app is more surface area than you need.

How the Tauri, Vue and TypeScript layers fit together

The repository is not an Electron app. The top-level entries include src-tauri/ alongside src/, index.html and vite.config.ts, and package.json exposes scripts named tauri, tauri:dev and tauri:build. Tauri runs the interface in the platform webview and the native side in Rust, so the shipped binary does not bundle a full browser runtime the way an Electron build does.

The front end is Vue with TypeScript, built by Vite. The src-shared/ directory sits next to src/ at the top level, which suggests code shared between the app and something outside it, and packages/ holds additional workspace content. The build pipeline is conventional: vue-tsc for type checking, ESLint and Stylelint for linting, Vitest for unit tests, and a separate e2e-webdriver/ directory with its own package that drives WebDriver tests. The e2e scripts include test:e2e:webdriver:skip-build, which sets SFM_SKIP_TAURI_BUILD_FOR_WEBDRIVER=1 so the Tauri binary is not rebuilt on every test run, and test:e2e:webdriver:install-edge-driver for the Edge driver. That is a Windows-oriented test setup, which lines up with the README's claim that Sigma can replace File Explorer for most everyday file actions on Windows.

Extensions are the part with the most architectural weight. The README says extensions can add commands, pages, shortcuts and settings, and that they install from a built-in marketplace or from local folders. That means the app has a plugin surface, not just a settings screen. The README also points at extension-provided features such as video downloading from over 1000 sites, a media converter and an image size optimizer. Those are not in the core app; they are examples of what the extension API allows.

Installing Sigma File Manager on Windows and Linux

The README points to the GitHub releases page for downloads, and the repository carries packaging directories for flatpak/ and snap/, plus a package.json script named flatpak:build that runs bash ./flatpak/build-flatpak.sh. On Windows the README gives `winget install sfm`, plus a Microsoft Store listing and an unsigned .exe installer. On Linux it lists a portable .AppImage (experimental) and a .flatpak installable, and the repository also carries snap/ packaging.

Building from source is possible. Node 24.16.0 is pinned in the volta block, and the engines field requires >=24.16.0.

npm install
npm run tauri:dev

The first command installs dependencies. The second runs sync-version and then tauri dev, which compiles the Rust side and opens the app against the Vite dev server. On a machine where the webview renders poorly, the repository provides a variant that disables compositing.

npm run tauri:dev:webkit-igpu

That script sets WEBKIT_DISABLE_COMPOSITING_MODE=1 before launching, which is the workaround the project ships for webkit rendering problems on Linux. For a release build the project uses tauri:build, and on Linux a separate script keeps debug symbols.

npm run tauri:build:linux

This runs the same build with NO_STRIP=true. The check script runs type checking, linting and unit tests together.

npm run check

On Windows there is a wider variant, npm run check:win, which adds the WebDriver end-to-end suite. Both are defined in package.json, so they are the project's own definition of a clean tree.

Where Sigma File Manager is the wrong tool

Network locations are the clearest limitation. The README lists them as alpha stage and names SSHFS, NFS, SMB and CIFS. Alpha in this project's own vocabulary is a stage below the stable v2 line, so anyone whose daily work happens on a mounted network share should treat that feature as unfinished and keep the system file manager for those paths. The same caution applies to WSL drives, which the README says are detected on Windows; detection is not the same as full read and write parity, and the README does not describe the limits.

The performance claim deserves the same care. The README states that global search finds files and folders in seconds and searches a full 1TB drive in roughly two seconds. That is the project's own figure for its own search index, and it says nothing about a slower disk, a network path or a directory tree with millions of small files. The typo correction system is also a search feature, not a data integrity feature: it helps you find a file whose name you half remember, and it will not help you if the file is on a volume the app cannot see.

Platform support is the third boundary. The README says macOS is supported but builds are not provided, and the repository's packaging directories are for flatpak/ and snap/, which are Linux formats. If your team is mixed, Sigma File Manager will not be the common tool. Finally, the extension marketplace is a supply chain you opt into. The README does not describe a review process for marketplace extensions, so installing one is a decision about trusting its author, the same as any plugin system.

Sigma File Manager compared with Nemo and the system explorer

Nemo is a useful comparison, and the two tools take opposite approaches. Nemo is a GTK file manager that grew out of the GNOME stack and is packaged by Linux distributions as part of their desktop. It integrates with the system theme, the system trash and the system mount handling, and it is typically installed with the distribution's package manager rather than downloaded from a releases page. Sigma File Manager is a self-contained Tauri application with its own interface, its own search index and its own extension marketplace. It does not inherit the desktop's look or its mount behaviour, which is why its network locations are a separate feature rather than a given.

The practical difference shows up in what you get for free. With Nemo, SSH and SMB mounts come from GVFS and the desktop environment, so they work the day you install the desktop. With Sigma File Manager, those connections are an alpha feature inside the app. In exchange, Sigma offers tabs, split view, a command palette, tags, a dashboard and a plugin API in one app for Windows and Linux. Nemo does not aim at Windows at all.

Against the built-in Windows File Explorer, the difference is smaller than the feature list suggests, because Explorer already handles the everyday operations. Sigma's argument is the interface: tabs, two independent panes, keyboard-first navigation with path autocomplete, glob and property filters for large folders, and Space to preview images, video, audio, PDFs and text without opening another program. If none of those change how you work, Explorer is already installed and already integrated.

Maintenance, release cadence and licence status

The repository is not archived, and the last push was on 2026-10-28. Recent releases are v2.1.0 on 2026-05-24, v2.2.0 on 2026-07-17 and a Linux test build using the Chromium engine (linux-cef-test-1) on 2026-10-28. The README states that v2 moved from beta to stable and that v2 became the main branch. The version in package.json matches the newest release at 2.2.0, which means the source tree and the published release are in step.

Upgrade cost depends on how you installed it. The README lists in-app updates: the app downloads and installs updates from update notifications, which is the lowest-effort path and keeps you on the release channel. Package-manager installs through Winget, the Microsoft Store or Flatpak move at the speed of the maintainer of that package, so a version can lag the GitHub release. Building from source means you own the upgrade: pull the branch, run npm install, and rebuild with npm run tauri:build. The version sync is handled by a script, sync-version, which tauri:dev and tauri:build both run first, so the app version stays aligned with package.json.

The licence needs your own reading. The repository reports NOASSERTION, which means GitHub could not map the LICENSE.md file to a known identifier. A NOASSERTION result is not a licence and not a permission; it is a signal that the file needs to be read directly. If you plan to redistribute the app, bundle it into a product, or fork it, read LICENSE.md before you build anything on top of it. The README also links a PRIVACY_POLICY.md at the repository root, which is worth opening if you care about what the app sends when it checks for updates or talks to the extension marketplace.

Editorial conclusion

Adopt Sigma File Manager on Windows if you want tabs, split view, a command palette and LAN sharing without paying for a commercial explorer, and on Linux if you install it through the Flatpak or AppImage builds rather than building from source. Skip it if you work on macOS, since the README says macOS builds are not provided, or if you depend on SSHFS, NFS, SMB and CIFS mounts, which the README still labels alpha. Before you commit, download the v2.2.0 release for your platform, confirm that the package channel you use tracks that version, and check LICENSE.md yourself, because the repository reports a NOASSERTION licence and the README does not resolve it.

Frequently asked questions

Official sources

1. aleksey-hoffman/sigma-file-manager on GitHub
2. Issues
3. README
4. Releases