# Wayland by FerroxLabs: a local-first desktop agent that drives your other AI CLIs > Wayland is an Electron desktop app with a Rust engine that runs on your machine and orchestrates Claude Code, Codex, Gemini and other AI CLIs from one place. It is AGPL-3.0, it keeps memory in SQLite across sessions, and it is not the Wayland display server. **FerroxLabs/wayland** — Wayland - The AI Agent That Perceives. Reasons. Acts. Evolves. - Repository: https://github.com/FerroxLabs/wayland - Website: https://getwayland.com - Stars: 607 · Forks: 113 - Language: TypeScript - License: AGPL-3.0 - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/ferroxlabs-wayland ## The problem: AI CLIs that never meet The README states the case plainly: your CLIs are "brilliant strangers who never met", each one forgetting everything between sessions and living in its own silo. That is the problem Wayland targets. If you use Claude Code for one task, Codex for another and a local model through Ollama for a third, you are the integration layer. You copy context between terminals, you re-explain the project, and you keep the plan in your head. Wayland is for people who already pay for or run several of those tools and want one desktop application in front of them. The README describes it as a command center and as a full agent in its own right, running on your keys and your files. It is not aimed at someone who wants a single chat window onto a single model. It is aimed at the person running a multi-week project who needs state to survive the session boundary. The name is a genuine problem for anyone searching. Wayland is also the Linux display protocol, and a town in Massachusetts. The repository is FerroxLabs/wayland, published at getwayland.com, and it has nothing to do with either. ## How the engine, memory and sandbox fit together The repository layout shows two halves. The desktop application is Electron and TypeScript, built with electron.vite.config.ts and packaged through electron-builder.yml. The engine is Rust, and the Dockerfile builds one Rust component explicitly: native/constitution-fs, compiled to a binary called wayland-constitution-fs, then staged into the bundle by scripts/prepareConstitutionFs.js. The build comments describe that binary as a "digest authority", which suggests the engine verifies what it executes rather than trusting the JavaScript layer to do so. Memory is the second mechanism. The README says memory persists across sessions in five SQLite-backed partitions. That is the concrete difference from a chat window: the plan and the project state have a place to live between runs, and the assistant is not re-deriving context from scratch. Sandboxing is the third. The README states that shell commands run through the bundled engine inside a native per-OS sandbox behind a single egress chokepoint: bubblewrap on Linux, sandbox-exec on macOS, and on Windows a kill-on-close Job Object by default, with AppContainer available through the environment variable WAYLAND_SANDBOX=appcontainer. It also states, without softening it, that tools the desktop app dispatches itself run with your account's privileges, and points at the desktop security model page for which path applies where. That distinction is the one worth reading before you hand the agent a shell. On top of that sit two shipped indexes that the README counts explicitly: 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. Those files are packaged as critical resources and loaded by SkillLibrary. ## Installing Wayland and running a first task The README points at the releases page for a download and lists macOS, Windows and Linux as supported platforms. There is also a Homebrew directory and an installer directory in the repository, though the README does not spell out the brew command, so treat the release download as the documented path. After installing, the README says you paste one key and start working. If you would rather build from source, the justfile is the entry point. Its dev recipe runs the Electron and Vite development server with hot reload. The justfile sets PowerShell as the shell on all platforms, which is worth knowing before you run it on Linux or macOS. ```bash just dev ``` That maps to bun run start in package.json. The same file defines a web UI mode and a multi-instance mode for running two copies side by side: ```bash bun run webui bun run start:multi ``` Before building anything, the justfile has a preflight recipe that checks six prerequisites. Its first check is Node.js, and it warns rather than fails below version 22. Run it first if a build fails in a way you cannot explain. ```bash just preflight ``` For a server deployment rather than a desktop install, the Dockerfile builds a runtime image on oven/bun, exposes port 3000, sets DATA_DIR=/data and declares /data as a volume. Remote access is off by default; the Dockerfile comment says to opt in with ALLOW_REMOTE=true only when the server sits behind authentication and TLS. The image's command is bun dist-server/server.mjs. On first run, start in Plan mode. The README describes it as read-only, letting you see the approach before anything on disk is touched. That is the cheapest way to find out whether the agent's reading of your project matches yours. ## Where Wayland gets in the way The distribution size is the first constraint. The README's own build notes record the engine binary at roughly 84 MB on darwin-arm64 and roughly 103 MB on linux-x64 at v0.13.11, and the notes instruct maintainers to re-measure rather than quote a remembered figure. Whatever the current number is, you are shipping a Rust engine alongside an Electron app, and that is a large install for a tool that sits in front of other tools. The Windows sandbox is weaker by default. The README is direct about this: Linux gets bubblewrap, macOS gets sandbox-exec, and Windows gets a kill-on-close Job Object unless you set WAYLAND_SANDBOX=appcontainer. If you are on Windows and you care about process isolation, the default is not the strongest option available, and you have to know the variable exists to change it. The security model is split, and the split matters. Tools the desktop app dispatches itself run with your account's privileges. The sandbox covers what the engine runs. If your mental model is "everything the agent does is sandboxed", the README's own wording corrects it. Finally, the README contains a maintainer note about its own counts: the file once claimed 177 workflows while the website claimed 107, and both were counting real things without saying which. That is a useful signal about how fast the surface area is moving. Any number you read here, including the ones above, is a measurement with a date attached, not a stable property of the project. ## Wayland against a single-CLI workflow The obvious alternative is what you are probably doing now: one CLI, one terminal, one model. Claude Code on its own is a capable agent with file access and a shell. It is also the thing Wayland is designed to sit on top of, not replace. If one CLI covers your work, Wayland adds an Electron app, a Rust engine and a sandbox layer between you and a tool that already worked. The real difference is where state lives. A single CLI forgets between sessions; the README's claim about Wayland is that memory persists in five SQLite partitions and that teams of assistants work against one shared blackboard. If your work fits in one sitting, that machinery is overhead. If your work spans weeks and several tools, it is the part you cannot easily build yourself. The second alternative is the general-purpose agent frameworks. Those give you a library and expect you to write the orchestration. Wayland gives you a desktop application with 88 bundled assistants, 178 workflows and a scheduler, and asks you to accept its opinions about how a team is assembled. The trade is control for a working default. Neither is wrong; they suit different people. One boundary worth stating: the repository topics include acp and mcp, and there is an examples/ directory with extension samples such as examples/hello-world-extension, examples/acp-adapter-extension and examples/ext-feishu. Channel integrations exist. What the README does not document is a stability guarantee for that extension surface, so treat extensions as something to read the source for before you depend on them. ## Licence, upgrades and what maintenance costs you Wayland is AGPL-3.0, and package.json records the SPDX identifier as AGPL-3.0-or-later. The practical consequence for most readers is the network clause: if you modify the software and let users interact with it over a network, the AGPL's terms reach that deployment in a way the GPL's do not. Running the Docker image for your own team is a different situation from offering a modified version as a service. The repository also carries a TRADEMARK.md and a LICENSES/ directory, which is a sign the maintainers have thought about the boundary between code and name. None of this is legal advice; read the licence text and the trademark file, and talk to counsel if you plan to redistribute. The upgrade cost is real. The release cadence is fast: v0.12.13 on 2026-09-04, v0.12.14 the same day, v0.12.16 on 2026-09-07, with the package version at 0.13.0 and the README's build notes referencing v0.13.11. That is a lot of version movement in a short window. The last push to the repository was on 2026-09-08, so the project is moving, and pinning a release rather than tracking main is the lower-variance choice. There is also a build-time dependency on network-fetched assets. The prebuild script runs scripts/prepareConstitutionFs.js, scripts/prepareVoiceModel.js, a models.dev snapshot verification and a skill-pack build. Those steps assume the snapshot and the skill pack can be produced in your environment. If you build from source in an offline CI, that is where it will fail. ## What to check before you commit Read the desktop security model page before you give the agent a shell, and confirm which tools run sandboxed and which run with your account's privileges. On Windows, decide deliberately whether the default Job Object is enough or whether you want AppContainer. On any platform, run the first session in Plan mode and watch what the agent proposes to read and write. If you are building from source, run just preflight first and check the Node.js version against the recommended floor. If you are deploying the server image, leave ALLOW_REMOTE unset unless the container is behind authentication and TLS, and mount the /data volume so the SQLite partitions survive a container replacement. Finally, pick a release tag and stay on it. The counts in the README move between versions, and the repository's own notes say the README and the website have drifted apart before over exactly that. If a number matters to your decision, measure it in the version you installed. ## Conclusion Adopt Wayland if you already run several AI CLIs and want one desktop surface with shared memory, scheduled jobs and a sandboxed shell, and if you are comfortable with an AGPL-3.0 application that ships a large bundled engine. Do not adopt it if you need a stable plugin ABI, if you want a headless server that is remote-accessible out of the box, or if you are looking for the Wayland display protocol. Verify two things first: that your platform's sandbox path is the one you expect, and that the skill-pack layout under src/process/resources matches the version you pin. ## FAQ ### What exactly is Wayland by FerroxLabs? It is a local-first desktop AI agent built with Electron and TypeScript, with a Rust engine, that runs on your machine and drives other AI CLIs such as Claude Code, Codex, Gemini and Qwen from one application. The README describes it as both a full agent in its own right and a command center for the CLIs you already use. ### How do I install Wayland and run it for the first time? The README points at the releases page for a download on macOS, Windows or Linux, after which you paste one API key. To build from source instead, run just dev, which maps to bun run start in package.json, and run just preflight first to check the six build prerequisites. ### How do I use Wayland on Linux? The README lists Linux as a supported platform and the Dockerfile builds a Linux server image on oven/bun that exposes port 3000 and stores data in the /data volume. On Linux the engine's shell commands run inside bubblewrap, according to the README's description of the per-OS sandbox. ## Sources - [FerroxLabs/wayland on GitHub](https://github.com/FerroxLabs/wayland) - [License: AGPL-3.0](https://github.com/FerroxLabs/wayland/blob/main/LICENSE) - [Project website](https://getwayland.com) - [README](https://github.com/FerroxLabs/wayland/blob/main/README.md) - [Releases](https://github.com/FerroxLabs/wayland/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ferroxlabs-wayland