# komorebi: a tiling window manager for Windows, built on top of DWM

> komorebi extends Microsoft's Desktop Window Manager with tiling layouts, virtual workspaces and a CLI you drive from whkd or AutoHotKey. It is a Rust workspace under a non-commercial licence, and the licence is the first thing to check before you install it.

**LGUG2Z/komorebi** — A tiling window manager for Windows 🍉

- Repository: https://github.com/LGUG2Z/komorebi
- Website: https://lgug2z.github.io/komorebi/
- Stars: 15,223 · Forks: 360
- Language: Rust
- License: NOASSERTION
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/lgug2z-komorebi

## What komorebi solves on Windows

Windows has never shipped a tiling window manager. You get snap layouts, which place a fixed number of windows in fixed regions, and you get virtual desktops, which are per-monitor only in the loosest sense. Neither gives you a tree of windows that reflows when one closes. komorebi is aimed at people who have used i3, bspwm or similar on Linux and want the same interaction model on Windows without giving up the Windows shell.

The README describes it as "a tiling window manager that works as an extension to Microsoft's Desktop Window Manager in Windows 10 and above". That framing matters more than it looks. komorebi does not replace the compositor or draw its own decorations. It manages windows that DWM already owns, which is why the project states it "aims to make as few modifications as possible to the operating system and desktop environment by default". Anything beyond that, such as hiding the taskbar, is opt-in and off by default.

The intended user is someone comfortable wiring up their own keybindings. komorebi exposes a CLI and expects third-party software to call it. The README names whkd and AutoHotKey as the two options, and there is a komorebic.lib.ahk file in the repository root for the AutoHotKey route. If you want a window manager that ships with a default keymap you never touch, this is not that.

## How the komorebi workspace is put together

The repository is a Cargo workspace with nine members: komorebi, komorebi-client, komorebi-gui, komorebi-layouts, komorebic, komorebic-no-console, komorebi-bar, komorebi-themes and komorebi-shortcuts. The split tells you most of the architecture. komorebi is the daemon that talks to the window manager API. komorebic is the CLI that sends it commands; komorebic-no-console is the same thing built without a console window so that keybindings do not flash a terminal. komorebi-client is the shared client used to reach the daemon, and the workspace depends on uds_windows, a Unix domain socket crate for Windows, which is consistent with a local daemon-and-client split rather than a network service.

The daemon side is heavily Windows-specific. The workspace pins the windows crate at version 0.62 and enables features including Win32_Graphics_Dwm, Win32_UI_Accessibility, Win32_UI_HiDpi, Win32_System_RemoteDesktop and Win32_Graphics_Direct2D. Win32_Graphics_Dwm is the DWM integration the README describes. Win32_UI_Accessibility is what a window manager needs to observe and manipulate other processes' windows. Win32_System_RemoteDesktop is worth noting because it implies awareness of RDP sessions, though the README does not document behaviour over Remote Desktop.

Configuration is JSON with a published schema. The root contains schema.json, schema.asc.json and schema.bar.json, and the justfile has two install paths: install-target uses --no-default-features, while install-target-with-jsonschema omits that flag. The README links a "complete configuration schema reference", so the schema files are the authoritative description of what keys exist. The workspace also uses serde_yaml, so YAML appears somewhere in the configuration surface, but the README's examples are described as JSON schema-backed.

## Installing komorebi and sending a first command

The README does not carry install steps. It points at the documentation site, specifically the installation page at lgug2z.github.io/komorebi/installation.html, and that page is where you should start. What the repository does show is how the maintainer builds and installs the binaries locally, via a justfile that sets the shell to pwsh.exe and installs six targets.

The justfile defines an install recipe that installs komorebic, komorebic-no-console, komorebi, komorebi-bar, komorebi-gui and komorebi-shortcuts. Running it requires just and a stable Rust toolchain:

```bash
just install
```

There is a second recipe, install-with-jsonschema, which installs the same six targets but without --no-default-features. The difference is that the plain install path strips default features, so if you want JSON schema validation for your configuration file, use the other recipe:

```bash
just install-with-jsonschema
```

Underneath both, each target is built with cargo +stable install --path <target> --locked. If you only want the CLI and the daemon, the justfile's install-target recipe takes a single target name, so the same command shape works for a narrower install. The README does not document the resulting binary paths; the justfile's copy-target recipe copies from .\target\release\<target>.exe into $Env:USERPROFILE\.cargo\bin, which is where cargo installs normally place them.

Once the daemon is running, control goes through komorebic. The README does not print a first command, but it does say the CLI reference lives at lgug2z.github.io/komorebi/cli/quickstart.html, and that the CLI is meant to be called from whkd or AutoHotKey rather than typed by hand. Start with the CLI quickstart page rather than guessing flags: every command name and argument belongs to that reference, and inventing one will simply fail.

## Licensing is the real adoption constraint

komorebi is not open source in the OSI sense. The README calls it "educational source software" and states it is licensed under the Komorebi 2.0.0 license, which it describes as a fork of PolyForm Strict 1.0.0. The plain-language summary in the README is that you may do what you want with it for personal use, other than redistribution or distribution of new works, meaning hard forks.

The README is explicit that the licence "does not permit any kind of commercial use (i.e. using komorebi at work)". Commercial use is handled separately through an Individual Commercial Use License, and the README carries a live badge counting active individual commercial use licences. If you are evaluating komorebi for a work machine, that is the decision point, not the feature list.

There is a second, narrower case. Students on devices enrolled in mobile device management still fall under Komorebi 2.0.0, but they see a splash intended for corporate users. The README describes a manual removal process: email the address the maintainer signs commits with, from your institutional address, with the subject "komorebi - student with an MDM device", and expect a reply, usually within 12 hours and with a 24-hour window before you should follow up on Discord. That is a human in the loop, and it is worth knowing before you plan a rollout. This is a description of the licence terms, not legal advice; read LICENSE.md and the licence repository yourself.

## MDM prompts, forks and other failure modes

The README devotes a section to unexpected mobile device management detection prompts. The explanation offered is that the device has most likely been enrolled in a Bring Your Own Device MDM profile without the user intending it, and the suggested check is dsregcmd /status. If you see a corporate splash on a machine you own, that is the first thing to run, not a komorebi bug report. This is an unusual amount of README space for a window manager, and it reflects how the licence is enforced rather than how the tiling works.

The harder limitation is the fork restriction. Anyone may fork komorebi for personal use or to send changes upstream as pull requests, but distributing new works based on it is not permitted. If your organisation needs to ship a patched window manager to employees, or if you want to vendor komorebi into a product, the licence blocks that path. The README points at komorebi-for-mac as a separate repository, which is a separate project rather than a port you can reuse.

Finally, the CLI-first design is a limitation in itself. komorebi does not ship a default set of keybindings that work out of the box; the README expects whkd or AutoHotKey to supply them. A user who is unwilling to write a keybinding file, or who expects a graphical settings panel, will find komorebic commands with no way to invoke them. The komorebi-gui member exists in the workspace, but the README does not describe it as a configuration interface.

## How komorebi compares with GlazeWM

The obvious alternative in this space is GlazeWM, another tiling window manager for Windows, written in TypeScript and distributed under an MIT licence. The difference in approach is architectural and it shows up in daily use. GlazeWM bundles its own configuration format and its own keybinding handling, so a single config file defines both the layout behaviour and the shortcuts. komorebi splits those concerns: the daemon manages windows, a CLI issues commands, and a separate program owns the keyboard.

That split is the reason komorebi can be driven by AutoHotKey, which is a genuine advantage if you already have an AutoHotKey script doing other things on the same machine. It is also the reason a first-time setup takes longer. With GlazeWM you edit one file; with komorebi you install a daemon, install a CLI, and then write keybindings in whkd or AHK that call the CLI.

The licensing difference is starker than the technical one. GlazeWM's MIT licence permits commercial use and redistribution. komorebi's Komorebi 2.0.0 licence permits neither. For a personal machine the licence rarely matters; for anything with an employer attached, it decides the comparison before performance or layout quality enters the discussion.

## Release cadence and what upgrading costs you

The repository is not archived, and the last push was on 2026-09-20, the same day as the nightly release. The most recent tagged release is v0.1.41 from 2026-05-03, preceded by v0.1.40 on 2026-02-14. Between those tags the project publishes nightlies, and the nightly entry carries a commit hash as its version string. That means the stable tags are roughly quarterly while the nightly channel moves continuously, and anyone who wants a recent fix is choosing between a tag that may be months old and a build identified only by hash.

For upgrades, the justfile is the relevant surface. install-target builds with --locked, so Cargo.lock is respected and a rebuild will not silently pull newer dependency versions. The workspace also has a rust-toolchain.toml and a flake.nix with flake.lock, so the toolchain and the Nix environment are both pinned. Configuration compatibility is a separate question: the repository ships schema.json and schema.asc.json, and the justfile's install-with-jsonschema path exists precisely so that configuration can be validated against the schema. Running that install path is the concrete way to catch a config key that a newer build has renamed or removed. The README does not document a migration guide for configuration between releases.

## Conclusion

Adopt komorebi if you run Windows 10 or above, want tiling and virtual workspaces without replacing the shell, and your use is personal: the Komorebi 2.0.0 licence permits personal use but does not permit commercial use, so anyone using it at work falls under the separate Individual Commercial Use License. Do not adopt it if you need a redistributable or hard-forkable window manager, or if you want a project that accepts patches under an OSI licence. Before installing, read the installation page rather than the README, confirm which of the workspace binaries you actually need, and check whether the splash applies to your device.

## FAQ

### How do I install komorebi on Windows?

The README does not list install steps; it points to the installation page at lgug2z.github.io/komorebi/installation.html. The repository's justfile shows the maintainer's own path, where just install builds and installs six workspace targets with cargo +stable install --locked --no-default-features, and just install-with-jsonschema does the same with default features enabled.

### How do I use komorebi for tiling?

komorebi runs as a daemon that manages windows through Microsoft's Desktop Window Manager, and you control it by sending commands through the komorebic CLI. The README expects those commands to be bound to keys using whkd or AutoHotKey, and it links a CLI quickstart reference for the command set.

### Can I use komorebi with yasb?

The README does not mention yasb. It does ship a komorebi-bar workspace member and a schema.bar.json file, so a status bar exists inside the project, but the README gives no instructions for pairing komorebi with third-party bars.

### Does komorebi run on Linux?

No. komorebi is built as an extension to the Windows Desktop Window Manager and the workspace pins Windows-only crates such as uds_windows and the windows crate with Win32_Graphics_Dwm. The README separately points to komorebi-for-mac for macOS, and does not offer a Linux build.

## Sources

- [Issues](https://github.com/LGUG2Z/komorebi/issues)
- [LGUG2Z/komorebi on GitHub](https://github.com/LGUG2Z/komorebi)
- [Project website](https://lgug2z.github.io/komorebi/)
- [README](https://github.com/LGUG2Z/komorebi/blob/master/README.md)
- [Releases](https://github.com/LGUG2Z/komorebi/releases)

---

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