Inspect Omarchy before deciding whether to run it
Installation instructions answer “how do I start?” A source inspection answers a narrower question first: “what does this exact revision say it will install, launch, or change?” This guide demonstrates that read-only step against the official Omarchy v4.0.4 source without installing Omarchy, running its scripts, downloading its ISO, or testing its runtime behavior.
The pinned inspection
On September 20, 2026, the official omacom/omarchy tag v4.0.4 resolved to full commit c668141e9c42b13c80c9ca4ea108e11708c5e8a5. Six text blobs were acquired from that commit and hashed as raw bytes. The downloadable source-inspection record preserves the tag, commit, paths, byte counts, SHA-256 digests, and claim boundary; the blank inspection checklist is reusable for another revision.
The release page displayed the short commit c668141 with GitHub's verified-signature indicator. That is a report of repository-host metadata, not an independent signature verification. The tag-to-commit resolution and blob hashes are the evidence actually produced for this guide.
| Inspected path | Bytes | SHA-256 | What it can support |
|---|---|---|---|
README.md | 2,831 | b79a649d…08d63 | Project positioning and documented system scope |
LICENSE | 1,063 | 717ba194…af4a2 | License text present at this revision |
manual/17-ai.md | 7,595 | 02408eca…1e85d | Documented AI launcher and unattended-mode behavior |
bin/omarchy-agent | 4,241 | 1e1b1ff1…b6a8e | How the default-agent launcher builds commands |
bin/omarchy-mise-install | 2,106 | b57b0be2…ff16 | How a mise-backed command wrapper is written |
bin/omarchy-default-agent | 3,777 | a408c3bd…c48a5 | Documented default-agent selection and install path |
The ellipses above are display abbreviations only. The downloadable record contains every full digest.
Finding 1: “lazy launcher” is visible in documentation and source
The AI manual at the inspected commit describes coding-agent commands as mise-managed stubs under ~/.local/bin, downloaded on first invocation. The inspected bin/omarchy-mise-install text supports the mechanism: it writes a wrapper that asks mise to select a package before executing a named binary.
That source inspection establishes declared implementation shape. It does not show that a package server was reachable, a binary was downloaded safely, a particular wrapper worked on hardware, or an agent authenticated successfully. None of those paths ran here.
Finding 2: launch paths can change approval behavior
The manual says keybinding and prompt launches run agents unattended, and its direct terminal shortcuts use auto-approving modes. The inspected bin/omarchy-agent text also identifies menu and keybinding launches as unattended and constructs different command arrays for supported harnesses, including their respective flags.
This matters during evaluation: “launches the same agent” does not mean “uses the same review boundary.” Record the exact invocation and flags, not just the harness name. This guide does not judge whether those modes are appropriate, prove what a downstream CLI does with a flag, or claim a host sandbox contains the process.
Finding 3: selecting a default may cross an installation boundary
The AI manual says choosing a default agent installs it if needed. The inspected bin/omarchy-default-agent text branches among package identifiers and specialized installers, checks whether the selected agent is present, and invokes an install path before recording the default.
That is enough to mark default-agent selection as a potentially mutating step in a future test plan. It is not evidence that an install was attempted here, that all supported agents share one provider/account model, or that removal restores every file and setting.
What source text cannot answer
Static text can reveal paths, declared commands, defaults, and review questions. It cannot establish runtime network destinations, transitive package bytes, filesystem effects after execution, hardware compatibility, resource use, authentication behavior, rollback completeness, or whether a current upstream service behaves as the source expects.
A later runtime evaluation would need separate authorization and a disposable host. It should pin the exact release, capture the actual downloaded artifacts, deny credentials by default, observe file/process/network effects, exercise removal, and report failures. Do not turn this read-only record into an installation recommendation.
Reuse the inspection method
- Resolve an official tag to a full commit before reading individual files.
- Select paths because they support named questions, not because the repository is easy to copy wholesale.
- Hash raw blob bytes and record exact byte counts.
- Pair every finding with the inspected path and a “does not establish” boundary.
- Keep execution, installation, hardware, and adoption claims in a separate evidence lane.
- Recheck volatile release metadata immediately before publication or action.
Primary sources
- Official repository
- Release
v4.0.4 - AI manual at the inspected commit
omarchy-agentat the inspected commitomarchy-mise-installat the inspected commitomarchy-default-agentat the inspected commit- License at the inspected commit
For the architectural companion, read Where Omarchy fits in an AI workstation.
Evidence boundary: source acquisition and hashing were actually executed; Omarchy installation, scripts, wrappers, agent commands, ISO, packages, network behavior, hardware behavior, and removal were not executed or tested.