# omacosy: an omarchy-style tiling desktop for macOS, built from six Swift binaries

> omacosy packages a tiling window manager, a themed status bar, trackpad workspace swipes and a live workspace overview into one MIT-licensed repo for macOS 26 on Apple Silicon. The install is a single script, but the permission surface is wider than most desktop tools and the project has only been run on the author's own machine.

**paulsp94/omacosy** — Pre-1.0. An omarchy-style desktop environment for macOS: tiling with a real Super key, dwindle layout, a themed status bar written for it, focus-follows-mouse, trackpad workspace swipes and a live workspace overview — ~157MB, six self-built Swift binaries, one repo. Built and tested on macOS 26 / Apple Silicon.

- Repository: https://github.com/paulsp94/omacosy
- Stars: 671 · Forks: 23
- Language: C
- License: MIT
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/paulsp94-omacosy

## What omacosy actually assembles

macOS ships a window manager that does not tile by default, and the third-party tiling tools that do exist each solve one slice of the problem. omacosy is an attempt to ship the whole slice at once: dwindle layout borrowed from Hyprland, a Super key produced by remapping Caps Lock, a status bar written specifically for the stack (bar, popups, sliders and screen dimming in one process), focus-follows-mouse, trackpad workspace swipes, a Mission-Control-style overview with live window previews, focused-window border rings, and a single theme switch that reaches down to the wallpaper.

The README states the environment idles at about 157MB of memory, with per-process numbers in a Memory use section that the cleaned excerpt does not include. The audience is narrow and clearly stated: someone who wants an omarchy-style Linux desktop experience on a Mac, is comfortable with Homebrew and shell installers, and is willing to approve a stack of privacy prompts. The repository describes itself as pre-1.0 and warns that "the permission setup is real work."

## Why the binaries are self-built instead of pulled from Homebrew

The README gives a blunt reason for the repository's shape: several existing tools are broken on macOS 26, so omacosy builds its own. The repo contains bin/, config/, helper/, themes/ and zsh/ directories, plus Brewfile, install.sh, macos-defaults.sh and uninstall.sh. The description counts six self-built Swift binaries; the README says "seven small signed binaries (Swift and C)" built by the installer. That discrepancy is worth noting if you plan to audit what lands on disk, because the two counts do not agree.

The mechanism is a generated config rather than a hand-maintained one. install.sh compiles the helper binaries and generates the AeroSpace config from your app choices, which means the window manager configuration is an output of the installer, not a file you edit directly in the usual dotfiles way. Configs are symlinked into the repo so that repository edits and live configuration stay the same file. The README also notes an alternative backend, OmniWM, which appears alongside AeroSpace in the permission table and in the option list for Input Monitoring. That suggests the installer can target either window manager, though the README excerpt does not spell out how the choice is made.

## Installing omacosy and running it for the first time

The README gives one command sequence for a fresh Mac, and it is explicit that the clone location matters. Run:

```bash
git clone https://github.com/paulsp94/omacosy.git ~/.local/share/omacosy &&
cd ~/.local/share/omacosy && ./install.sh
```

The reason for that path is macOS privacy (TCC), which blocks launchd services from reading ~/Documents, ~/Desktop and ~/Downloads. If you clone into one of those folders anyway, the installer falls back to copying configs instead of symlinking them. That still works, but subsequent edits need an install.sh re-run to take effect. The README also warns that the bar itself will hang at startup waiting on a Files and Folders prompt if the clone lives in a protected folder.

What install.sh does, in the order the README lists it: installs Homebrew if missing, runs brew bundle, compiles the helper binaries, generates the AeroSpace config from your app choices, symlinks configs while backing up anything it would replace, hides the native menu bar, applies the default theme, and starts the services. It is idempotent, and it uses no sudo and installs no LaunchDaemon.

Updates are wrapped in a single command:

```bash
omacosy-update          # pull, then re-run the installer
omacosy-update --check  # just say whether there is anything new
```

install.sh rebuilds only the binaries whose sources changed and restarts their agents. The update command refuses a clone with local edits and refuses one whose branch has diverged, rather than deciding either case for you. There is no background update check: the README says the bar makes exactly one network call, the weather, and a daemon polling GitHub on a timer would quietly make that two.

## The permission surface is the real adoption cost

This is where omacosy differs from a normal Homebrew package, and the README does not soften it. Accessibility is the broadest grant: AeroSpace or OmniWM, omacosy-gesture, omacosy-bar and omacosy-ffm all ask for it, and it is what moves, resizes and focuses other applications' windows. Without it, nothing tiles.

Input Monitoring goes to Karabiner-Elements and omacosy-gesture, because macOS 26 stopped carrying touch data in normal events and the gesture helper reads raw trackpad contacts. Screen Recording goes to omacosy-overview, which captures a thumbnail per window for the overview cards, including windows the window manager has stashed offscreen. A screenshot of the visible screen could not see those, so cards fall back to app icons and titles without the grant. Bluetooth, Location and Automation are narrower: the Bluetooth pill hides itself without its grant, the Location grant buys exactly one string (the wi-fi network name, which macOS classes as location data), and the Automation grant covers Apple Events to Spotify and to System Events.

The privilege question is the one to think hardest about. omacosy's own binaries never run as root, but Karabiner-Elements does, and the README says so plainly: it ships a DriverKit system extension plus daemons that run as root, and it is "the most privileged thing this repo puts on your Mac, and it is third-party." Karabiner is a Homebrew dependency here purely to turn Caps Lock into Super. Skip it and you lose the Super key and keep everything else.

One design choice deserves credit. The README states that every grant is refusable and that dependent parts hide themselves rather than half-work. That is a better failure mode than a bar that renders broken icons.

## Where omacosy is the wrong tool

The README is unusually direct about the project's limits, and they matter more than the feature list. It was built for macOS 26 (Tahoe) on one desk: a MacBook Pro plus one external display. It tries to generalize, using display roles instead of hardware names and per-display notch detection, but the README says it "has only run on this machine." If you are on macOS 15, on Intel, or on a multi-monitor setup with three or more displays, you are outside what has been exercised.

Support is explicitly not promised. The README says issues and PRs are welcome and support promises are not made. For a tool that holds Accessibility and Screen Recording, that is a real consideration: when something breaks after a macOS point release, there is no vendor to call.

A second failure mode is environmental. Clone into ~/Documents, ~/Desktop or ~/Downloads and the bar hangs at startup waiting on a Files and Folders prompt, and config edits stop applying until you re-run install.sh. That is a self-inflicted trap the README documents but cannot prevent.

Finally, the Super key depends on Karabiner-Elements running as root. If your threat model rules out a third-party DriverKit extension with root daemons, the central selling point of omacosy is unavailable to you, and what remains is a tiling setup you could assemble from its parts.

## How it compares to a plain AeroSpace setup

The closest reference point is AeroSpace itself, which omacosy uses as a backend and generates a config for. The difference is scope. A vanilla AeroSpace install gives you tiling and leaves the bar, the theme, the overview, the gesture layer and the Caps Lock remap to you. omacosy bundles all of those and wires them to one theme switch, at the cost of a much larger permission footprint and a stack you did not choose piece by piece.

That trade is the whole argument. If you already run AeroSpace with your own status bar, adopting omacosy means replacing a configuration you understand with an installer that generates one. The symlink design means edits still land in the repo, so it is not opaque, but the entry point is a script rather than a config file.

The README also points at omarchy, the Linux project the aesthetic and layout come from. omarchy is a complete Arch-based desktop; omacosy is the macOS reinterpretation, which means it inherits the layout conventions but not the underlying platform assumptions. Hyprland's dwindle layout is reproduced here, not the compositor that normally provides it.

## Licence, maintenance and the cost of upgrading

omacosy is MIT licensed, which permits commercial and private use, modification and redistribution provided the copyright notice and permission notice are included. That is permissive and unremarkable, and it is compatible with the Homebrew dependencies the installer pulls. Note that the licence covers this repository only, not Karabiner-Elements or the other brew bundle entries, each of which carries its own terms. Nothing here is legal advice; read the LICENSE file in the repo root if the distinction matters to your organisation.

The last push to the default branch was on 2026-09-15, two days before this writing, and the repository is not archived. No releases have been published, so there is no version number to pin and no changelog to read. Upgrades are pulls from main.

The upgrade cost is low by design. omacosy-update pulls and re-runs the installer, install.sh rebuilds only binaries whose sources changed and restarts their agents, and the command refuses to proceed on a clone with local edits or a diverged branch. That refusal is the right default: it stops the tool from silently discarding your work. The cost you actually pay is re-approving or re-checking permissions after macOS updates, which is inherent to any tool holding Accessibility and Screen Recording, and re-running install.sh if you cloned into a TCC-protected folder. There is no background update check and no telemetry, so nothing tells you a new commit exists unless you run omacosy-update --check.

## Conclusion

Adopt omacosy if you are on macOS 26 Apple Silicon, you want Hyprland's dwindle layout and a Super key on a Mac, and you accept granting Accessibility, Input Monitoring and Screen Recording to a pre-1.0 project that the README says has only run on one desk. Do not adopt it if you need vendor support, if you cannot install Karabiner-Elements (which runs as root), or if you keep your dotfiles in ~/Documents, ~/Desktop or ~/Downloads. Verify before committing: that your clone is not inside a TCC-protected folder, that you can live with the seven permission grants listed in the README, and that the AeroSpace or OmniWM backend it generates a config for is the one you want.

## FAQ

### What does omakase mean, and why is the project called omacosy?

The README expands the name as "omakase + macOS + cosy," framing the project as an omarchy-style setup for macOS. The omarchy reference points at the Linux desktop project it borrows its layout and aesthetic from.

### What is omakase and why is it so expensive?

The README does not discuss omakase pricing or the restaurant meaning of the term. It only uses omakase as a wordplay component of the project name, alongside macOS and cosy.

### What is omakase in Chinese?

The README does not translate omakase or address the term in Chinese. It defines the project name only as "omakase + macOS + cosy."

### What does "Omakase course" mean?

The README does not describe an omakase course. Its use of the word is limited to the project name expansion, and the rest of the documentation covers installation, permissions and the components of the desktop environment.

## Sources

- [Issues](https://github.com/paulsp94/omacosy/issues)
- [License: MIT](https://github.com/paulsp94/omacosy/blob/main/LICENSE)
- [paulsp94/omacosy on GitHub](https://github.com/paulsp94/omacosy)
- [README](https://github.com/paulsp94/omacosy/blob/main/README.md)

---

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