What Wayland is built on

Last updated: August 29, 2026

Wayland runs on your machine, holds your provider keys, reads your files and executes shell commands. That is a large amount of trust to ask for. This page is the evidence: where the code came from, what protects it, who profits from what, and — the part most pages leave out — what has not been independently verified.

Every claim below names the file it comes from. Clone the repository and check any of it.

What has not been audited

Wayland's sandboxing, its egress controls and its secret scrubbing have not been reviewed by an independent third party. The design is deliberate and the implementation is in the open, but no outside security firm has audited it. We do have a published advisory record: GHSA-8r7g-7556-hj3j, high severity, found and fixed by us and disclosed through GitHub's advisory process rather than quietly patched.

Everything below is engineering we did and can point you at. None of it is a substitute for an external audit, and you should not treat it as one. If you are deciding whether to give Wayland production credentials, that gap is the honest reason to wait — or to read the source yourself, which is why it is licensed the way it is.

Where the code came from

Wayland is not written from scratch, and the lineage is documented rather than buried.

The desktop app originates in part from AionUi (Apache-2.0) — parts of the Electron main process, the IPC bridge, renderer scaffolding, agent client protocol integration and MCP services. It has since diverged substantially.
The engine, Wayland Core, is a Ferrox Labs fork of aionrs (Apache-2.0). Every workspace crate was renamed, the binary and config paths changed, and the original Apache-2.0 copyright headers are preserved in all forked source.

The full notice, including the enumerated list of modifications required by Apache-2.0 §4(b), ships in the repository.

source: notices/THIRD-PARTY-NOTICES.md · notices/Apache-2.0.txt

Who makes money, and how

Wayland is free, AGPL-3.0, and requires no account. The engine is Apache-2.0 so anyone can embed it. There is no paywall and no telemetry gate.

Flux Router is also built by Ferrox Labs. It is a paid inference router, and Wayland can optionally send a backend's traffic through it. We are saying that here rather than letting you discover it: it is opt-in, off by default, requires its own separate key, and Wayland has no required backend of any kind. Delete the key and everything else keeps working, because the app never needed a server.

You can verify that claim rather than take it: run Wayland with only a direct Anthropic, OpenAI, or Ollama key and watch it work normally, or read the routing code.

Signing and distribution

macOS builds are signed and notarized by Apple. Windows builds are code-signed. You can check the shipped artifact yourself:

spctl --assess --type exec -vv /Applications/Wayland.app
xcrun stapler validate /Applications/Wayland.app

Gatekeeper reports source=Notarized Developer ID. Windows SmartScreen may still warn on a signed binary until the publisher accumulates download reputation; that is a reputation signal, not a signature failure.

The machinery you cannot see

Most of what protects a tool like this is invisible in normal use. It is in the repository, so here is where.

Supply-chain attestation ledger

Publisher attestations with a schema and a verifier, a ledger of every third-party executable that ships, and a registry of accepted dependency advisories.

src: scripts/supply-chain/publisher-attestations.json · verifyPublisherAttestation.js · third-party-executables.json

Release acceptance gates

Seventeen verifiers, covering the hardening matrix, a severe-dependency audit, release-authority verification and trust-root acceptance, enforced by three dedicated CI workflows. A release that fails any of them is blocked. Worth saying plainly: we have twice caught one of these gates reporting success without actually testing anything, once because it could not run and once because it asserted something that could never be true. Both repairs are in the history beside the gates they fixed. A gate that cannot fail is not a gate, and we would rather you knew we look for that than believe the machinery has never been wrong.

src: scripts/release-acceptance/ · .github/workflows/release-acceptance.yml · release-gates.yml · release-acceptance-trust-root.yml

Verified update, rollback and re-upgrade

Auto-update is the usual way tools brick themselves. The signed update path has a strict receipt schema, a runnable rollback-and-re-upgrade test, and a protected CI observer that runs the whole journey. The downgrade path is tested, not assumed.

src: src/process/services/updateAcceptanceReceipt.ts · scripts/run-updater-rollback-reupgrade.ts · .github/workflows/protected-updater-journey-observer.yml

Update quiesce gate

An agent that restarts itself mid-task is worse than one that never updates. Installs are deferred until agents, cron jobs and teams go idle.

src: src/process/services/updateQuiesceGate.ts

Runaway-session circuit breaker

A per-conversation loop detector that trips on repeated identical tool output or consecutive failing commands. It exists because a real session burned 8.5 million tokens before anyone noticed.

src: src/process/services/runaway/RunawayMonitor.ts

Webhook receiver hardening

Inbound webhooks are where local agents get compromised. The receiver has an SSRF guard, a replay cache, connection tokens, an audit log and per-provider signature verifiers.

src: src/process/channels/webhook/ — ssrf-guard.ts · replay-cache.ts · audit-log.ts · verifiers/

Windows Authenticode verification

Bundled third-party binaries are checked by reading the PE certificate table, proving they kept their upstream signature inside our installer rather than trusting that they did.

src: scripts/peAuthenticode.js

Startup bundle-integrity check

Packaged macOS builds verify their own code signature after launch and notify you if the seal is broken.

src: src/process/services/integrity/bundleIntegrity.ts

Recovery and disaster restore

An external recovery authority with its own cryptography, sealing, dry-run mode, a state-authority ledger and historical-transaction verification. Local-first only means something if you can actually get your data back.

src: src/process/services/recovery/ · contracts/recovery/state-authority-ledger.json

Antivirus false-positive gate

A blocking structural gate — zero loose scannable files, byte-exact round-trip — plus an EICAR-canary-gated Defender scan across the shipped skill pack.

src: .github/workflows/skill-pack-av.yml

Skill provenance

The library is a closed, first-party set: all 2,177 bundled entries — 1,974 skills, 178 workflows and 25 agent profiles — carry source: wayland-library. Nothing in it comes from a public marketplace; every entry was reviewed and scrubbed by us before it was bundled. Trust here is by provenance, not by an automated scan: the runtime stamps bundle-contained first-party content clean without reading the body, which is a deliberate choice — it avoids ~2,000 body reads on every boot, and a regex pass over content we wrote ourselves would prove nothing we did not already know. Anything you import from outside the bundle is a different matter, and goes through Skill Guard in full: rule-based scanning plus an LLM read of the body. A blocked verdict is not advice. The skill is quarantined, and SkillLibrary.loadBody refuses to load it, so a blocked import cannot run even by accident. Anything short of blocked surfaces for your judgement, and the permission prompt is still the last boundary at run time.

src: src/process/services/skills/SkillGuard.ts · src/process/services/skills/SkillLibrary.ts · scripts/stamp-bundled-skill-verdicts.mjs

Per-OS sandboxing

Shell execution runs inside the native sandbox for each platform: bubblewrap plus a compiled-in seccomp-bpf syscall filter on Linux, sandbox-exec on macOS. On Windows the shipping default is a kill-on-close Job Object, which bounds process lifetime and resource use but does not confine the filesystem — AppContainer, which does, is opt-in via WAYLAND_SANDBOX=appcontainer because the strict profile could not reliably launch a usable shell. The engine logs its Windows posture as relaxed on every start. We previously described Windows as AppContainer and Linux as Landlock on this page; both were wrong for the default build and are corrected here.

The Windows posture is a deliberate choice, not an unfinished one. AppContainer's restricted token could not reliably launch a usable shell — PowerShell will not run under it at all — and the alternatives were to ship a sandbox that blocks the product from working, or to go WSL-only and cut off most Windows machines. Several well-known agent CLIs have gone back and forth on exactly this, and at least one settled on WSL-only. We chose a weaker posture that runs, and made it announce itself: the engine logs posture = "relaxed" on every Windows start, tells you in-session that the shell is unconfined, and drops the Bash tool entirely from remote and channel sessions where it cannot prove secret-read-deny at the OS layer. If you want the strict profile, WAYLAND_SANDBOX=appcontainer restores it. What we will not do is call the default something it is not. This is the part with no independent audit — see the top of this page.

src: wayland-core (Apache-2.0) — github.com/FerroxLabs/wayland-core

Tests

1,920 test and spec files containing 18,216 test cases, which expand to over 21,000 executed assertions. They run on every pull request across macOS, Ubuntu and Windows. You can run them yourself with bun run test.

Licences

Wayland Desktop — GNU AGPL-3.0-or-later. Run it, self-host it, modify it, fork it. A networked service built on it must publish its source under the same terms.
Wayland Core — Apache-2.0. Permissive on purpose, so the engine can be embedded in anything.

Check any of this

git clone https://github.com/FerroxLabs/wayland
cd wayland

# the counts quoted across this site, measured from the shipped indexes
node scripts/check-public-counts.mjs

# the attribution lineage
cat notices/THIRD-PARTY-NOTICES.md

# the release gates that must pass before a build ships
ls scripts/release-acceptance/

Who builds this

Wayland is built by Ferrox Labs, an independent R&D lab. We are a small team and most of us are part-time. That is worth stating plainly, because the size of the shipped surface — 1,974 skills, 178 workflows, 98 assistants — reads like a much larger company, and the honest explanation is that we use Wayland to build Wayland.

It also means the usual assurances a bigger vendor offers are not ones we can make yet: no third-party security audit, no SOC 2, no 24/7 support rota. What we can offer instead is that every claim on this page is checkable from the source, and the checks are listed above. The lab's other work, including the research we have published and the things that did not work, is at ferroxlabs.com.

The capability matrix

Every capability Wayland ships is graded in one place — the Capability Status Matrix — as Shipped, Partial, Offline-only or Not-wired, with the source file behind each row. It is the authority: where it disagrees with this page, the marketing site or the README, the matrix is right and the other one is a bug.

It is not a summary of what works. It names what does not, including the rows we would rather not write, and it is the fastest way to find out whether the specific thing you need is finished before you install anything.

src: docs.getwayland.com/core/status-matrix

If something on this page does not match what you find, that is a bug in the page. Open an issue and we will fix it.