FerroxLabs/wayland: a local-first command center that drives your other AI CLIs

The problem Wayland targets: five CLIs that never met

The README states the case bluntly: your CLIs are "brilliant strangers who never met", each forgetting everything between sessions and living in its own silo. That is the actual pain. If you run Claude Code for one task, Codex for another and Gemini for a third, you re-explain your project every time, and no tool knows what the others did. Wayland positions itself as the layer above them: a local-first desktop app that drives those CLIs from one command center, with shared memory across agents and what the README calls multi-AI cross-audit. The intended user is a solo developer or small team already paying for multiple model subscriptions who wants one thread of work rather than five parallel conversations. It is not aimed at someone who has never used an AI CLI; the value only appears once you have several to reconcile.

What the repository actually contains: two skill indexes, an engine, and a catalog

The README's own HTML comment is the most concrete artifact in the material, and it is worth reading carefully because it documents a counting problem. It names three packaged resources loaded by SkillLibrary: src/process/resources/skills-library/index.json with 2,106 entries (1,974 skills, 107 workflows, 25 agent-profiles), src/process/resources/bundled-workflows/index.json with 71 workflows, and src/process/resources/builtin-catalog/assistants.json with 88 assistants. The comment notes zero name overlap between the two indexes, which is why they are counted separately rather than merged. The same comment records that the engine binary is roughly 84 MB on darwin-arm64 and 103 MB on linux-x64 at v0.13.11, and instructs maintainers to re-measure from the npm platform packages rather than quote a remembered figure. That instruction exists because the README once claimed 177 workflows while the website claimed 107, and neither stated what it was counting. Treat every number in this project's marketing copy as a measurement with a date attached, not a constant.

How the pieces fit: a Rust engine under a TypeScript and Electron shell

The repository's primary language is TypeScript, with Rust listed among the topics and the engine badge pointing at rust-lang.org. The README describes an engine that executes shell commands and a desktop app that dispatches its own tools separately, which is the distinction that matters for security. Skills, workflows and assistants are static JSON resources shipped as critical resources and loaded by SkillLibrary, so the agent's capabilities are partly pre-packaged rather than generated at runtime. Memory is described as five SQLite-backed partitions that persist across sessions. The README also claims the engine "rewrites and re-scores its own skill prompts against an eval harness", which is the most ambitious claim in the material and the one you should treat most cautiously: an eval harness is only as good as its eval set, and no eval set, scoring method or published result appears in the supplied text. Eighteen ACP backends are listed, and the topics include both acp and mcp, so the integration surface is protocol-based rather than a set of bespoke adapters.

Sandboxing: bubblewrap, sandbox-exec, and a Windows caveat worth reading twice

Wayland's security story is the most specific thing in the README, and it is also where the fine print lives. The README says shell commands run through the bundled engine inside a native per-OS sandbox behind a single egress chokepoint: bubblewrap on Linux and sandbox-exec on macOS. On Windows, the default is a kill-on-close Job Object, with AppContainer available by setting the environment variable WAYLAND_SANDBOX=appcontainer. That is a real asymmetry. A Job Object bounds process lifetime and resource usage; it is not the same class of isolation as bubblewrap. The README then adds the sentence that should govern your threat model: tools the desktop app dispatches itself run with your account's privileges, and the desktop security model page at docs.getwayland.com says exactly which is which. If you are evaluating this for anything sensitive, that page is the first thing to read, because the sandbox boundary does not cover everything the app can do.

Getting it running: install, one key, and the source build path

The README's stated onboarding is deliberately short: install it, paste one key, and start working. The download link points at github.com/ferroxlabs/wayland/releases/latest, with builds listed for macOS, Windows and Linux. The README also carries a build-from-source anchor, and the repository layout implies the usual Node toolchain plus a Rust toolchain for the engine binary, though the supplied material does not include the actual build commands, so I will not invent them. Two configuration surfaces are named explicitly. Flux Router routing is opt-in and described as sending each task to the model that fits it, with a link to fluxrouter.ai. WAYLAND_SANDBOX=appcontainer is the documented switch for Windows isolation. For fully local operation the README names Ollama as the local model path. Everything else about configuration, including where keys are stored and how the five memory partitions are named, is outside the material I have.

Where it is the wrong tool, and what to use instead

Wayland is a desktop application. If your workloads run on a headless build server, in CI, or inside a container you do not control, the per-OS sandbox design (bubblewrap, sandbox-exec, Windows Job Objects) assumes an interactive desktop session and does not map onto that environment. The alternative in that case is a framework-level approach: LangGraph or the OpenAI Agents SDK, where you write the orchestration graph yourself and run it wherever Python runs. The difference in approach is not cosmetic. Wayland ships 1,974 skills, 178 workflows and 88 assistants as packaged JSON and gives you a GUI to pick from them; a framework gives you an empty graph and expects you to define state, transitions and tool permissions in code. If you need an auditable, version-controlled orchestration definition that a reviewer can read in a pull request, the packaged-catalog model is working against you. If you want something usable this afternoon without writing an agent loop, it is working for you. A second case: if you only ever use one CLI, Wayland adds a layer without adding a second agent to reconcile, and the shared-memory argument loses most of its force.

Licence, upgrade cadence and the maintenance cost you are signing up for

The licence is AGPL-3.0, which is a network-copyleft licence: if you modify Wayland and let users interact with it over a network, the AGPL's source-availability obligation is generally understood to attach to your modified version. That is a summary, not legal advice, and the practical question for most engineers is whether they intend to modify and redistribute or host it. Internal desktop use of an unmodified build is a different situation from building a product on top of it. On maintenance, the release history shows v0.12.13, v0.12.14 and v0.12.16 all tagged within four days in early September 2026, which tells you the project moves quickly and that pinning to a specific release is wise if you depend on it. The README adds a related warning for anyone building on the repo: image URLs in the README are pinned to the main branch, and the comment advises pinning to a release tag before a wide launch so older releases keep rendering. The same discipline applies to the JSON indexes, since skill and workflow counts are explicitly described as measurements that drift.

What to check before you commit to it

Three things are worth verifying against the live repository rather than this description. First, confirm the engine binary size and the platform package contents for your OS, because the README itself says to re-measure from the npm platform packages rather than trust a remembered number. Second, read docs.getwayland.com/concepts/security-model-desktop/ and identify precisely which dispatched tools run with your account's privileges, since that determines whether the sandbox is your boundary or only part of it. Third, decide whether you are comfortable with AGPL-3.0 given your intended use, and if you are not, that decision comes before any technical evaluation. The project is not archived, the last push recorded is 2026-09-08, and the homepage is getwayland.com. Those are the facts the material supports; anything about model routing quality, skill accuracy or eval-harness results is a claim the README makes without showing its work.

Editorial conclusion

Adopt Wayland if you already pay for two or more AI CLIs and want one place to run them with shared memory and a per-OS sandbox, and if AGPL-3.0 is acceptable for how you intend to use it. Do not adopt it if you need a headless server-side orchestrator, or if you cannot tolerate a fast release cadence (three tagged releases in the first week of September 2026 alone). Verify first that the engine binary for your platform matches what the npm platform packages actually ship, and read the desktop security model page to confirm which dispatched tools run with your account's privileges rather than inside the sandbox.

Official sources

1. FerroxLabs/wayland on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases