AOS Community Edition: eight aos roots that displace the runtime behind them

Eight aos roots replace the runtime commands sitting behind them

AOS is a product layer over a pinned runtime, and the seam is drawn in verbs. The roots that belong to the product include init, status, migrate, update, distro, mcp, daemon, and serve-health. Everything else reaches the runtime unchanged, with arguments, exit codes, and signals passed through, and there is no nested aos astrid or aos runtime namespace to hide that behind. When AOS owns a root, its implementation sits at the same command location and displaces the lower-level one.

That has a consequence for anyone wrapping the tool. A new verb appearing in the runtime cannot slip into a product release by accident: release validation compares the exact pinned runtime's public command inventory against the AOS root contract, and a mismatch fails until somebody records an inherit-or-own decision. The other side of that choice is that the full supported surface stays aos followed by a verb, so a script expecting a namespace to walk into will not find one.

aos status
aos status --json
aos --principal codex-code mcp serve
aos daemon foreground --workspace /workspace

The pass-through side reads in one breath:

aos doctor
aos capsule build

Both forms are the same command with a different verb.

aos init works through ten-capsule batches, so a clean install waits about two minutes

The supported installer is one pipeline command, and it is not a package manager invocation you get to inspect first. It installs the aos product command, its pinned runtime, and the exact 22 Community Edition capsules built from this source tree, all under the product-owned ~/.aos root.

curl --proto '=https' --tlsv1.2 -fsSL https://aos.unicity.ai/install.sh | sh
aos init

What to expect after aos init is roughly two minutes of waiting. A fresh Community installation provisions from local, product-versioned capsule assets in Astrid's ten-capsule batches and automatically resumes after each rate-limit window. Completed installs are not repeated, so a second run is cheaper than the first, but a stalled batch stays an error rather than a warning, which means a provisioning script has to treat a non-zero exit as a real failure and rerun it.

Hosts that cannot reach the network during setup have an offline form that provisions from local, product-versioned capsule assets:

aos init --offline

Re-running the installer is not a reinstall either. It performs a coordinated product upgrade and leaves a standalone runtime installation alone, so the two install paths do not fight over the same files.

Three macOS floors, and native execution on 11 through 15 is untested

macOS support is split across three version numbers, and they are not the same number. The packaged aos binary and the bundled astrid and astrid-daemon binaries declare an LC_BUILD_VERSION of minos 11.0. Command Center declares LSMinimumSystemVersion 13.0 and is not copied onto hosts older than that. Optional Finder volume mounts follow the LSMinimumSystemVersion on AstridFS.app, which is currently 26.0.

The macOS notes are careful to say those floors are separate, and the practical result is that an older Mac still installs the CLI. What it does not get is Command Center, and below 26.0 the optional Finder volume mounts are unavailable too. For a mixed fleet, the honest summary is that aos runs on the oldest machines and the surrounding tooling quietly does not.

Native execution on macOS 11 through 15 is untested. That is a stated gap rather than an inference, and it sits directly under the oldest supported floor, so the range most likely to contain an older corporate laptop is the one nobody has run. Details live in release/MACOS-SUPPORT.md.

The local MCP bridge takes a boolean or the AOS approval enum, and nothing else

aos mcp serve is the shared edge for Codex, Claude, and Grok, and the interesting part is what happens when a client cannot render its own approval form. A client that supports MCP form elicitation keeps presenting its own constrained forms. When it does not, the default --interaction auto mode opens a local AOS decision surface: AppKit on macOS, a native Windows dialog, or Pinentry on Linux. The values client, native, and deny make the policy explicit instead of automatic.

aos --principal codex-code mcp serve

The constraint that decides whether this design fits your workflow is what the local bridge will accept: a single boolean, or the fixed AOS approval enum. Arbitrary strings, password-shaped fields, and URL elicitations are never collected through it. An approval flow needing free text, a typed secret, or a link the agent must follow cannot be served here, and pointing that flow at --interaction auto will not loosen it. --interaction deny makes the request fail closed instead, which is a safe answer and an unanswered one.

The principal flag matters for the same reason. AOS runs the serve command as a named principal rather than as whoever logged in, so the authority the model holds is fixed by configuration instead of inherited from the shell.

daemon foreground execs the bundled daemon on Unix and waits on it elsewhere

Supervised operation is where the two platforms genuinely diverge. On Unix, aos daemon foreground replaces the AOS process with the persistent bundled daemon, so the process a supervisor started stays the process it watches, with direct signal delivery and its own exit status. On other hosts the same command waits for the daemon and preserves its exit status instead.

aos daemon foreground --workspace /workspace

Both paths apply the same environment: the product-owned runtime home, the .aos workspace layout, the enforced Community Edition distro, and stderr logging. Carry that into a systemd unit or a Windows service definition and the point is that the supervision model differs by platform, so one cross-platform restart policy written against the Unix behaviour will not describe what a non-Unix host does.

One boundary the command never crosses: neither path enables ephemeral lifetime. A deployment that depends on a runtime discarding state when its lifetime ends will not get that from the foreground daemon, and no flag is pointed at in the command reference.

aos update --check authenticates metadata and will not tell you the archive arrived

Update checking has the most room to mislead, and the documentation pre-empts most of it. aos update --check authenticates the signed stable channel and reports availability. It does not install, does not restart the runtime, and does not change accepted channel state. A failed check exits nonzero, and a nonzero exit is not evidence that the installation is up to date. The check also needs the installed product updater to be present.

aos update --check
aos update --check --json

The JSON form puts one object on stdout with schema_version: 1, the installed and channel versions, the channel, the target, and the channel-selected artifact SHA-256. Read the verification field carefully: verification: "metadata" means the signed metadata passed verification, not that the product archive was downloaded or installed. Diagnostics go to stderr. The two version fields stay separate on purpose, because a differing channel version may be older than the installed one, so a channel that differs is not automatically an upgrade. JSON output requires --check and never applies an update.

Channel selection follows the install method. Homebrew installations update with aos update. Direct installs resolve the signed stable channel by default and can select dev, nightly, or an exact version, all of them fail-closed until their signed metadata is actually published.

Behind the channels sit two release gates. Every release publishes checksums, Sigstore bundles, GitHub build-provenance attestations, and runtime-compatibility.toml, which pins the exact runtime release and WIT commit. Both a machine-readable runtime-compatibility check and an upgrade and self-heal check must be true before a tag can publish, and the second is approved only after the exact candidate preserves a frozen standalone-home clone and boots with freshly generated runtime coordination state.

The release profile is opt-level z, one codegen unit, and panic abort

Reading Cargo.toml tells you more about AOS's priorities than the overview does. The release profile is:

[profile.release]
opt-level = "z"
lto = true
codegen-units = 1
strip = true

opt-level = "z" selects size over speed, lto with codegen-units = 1 pushes cross-crate optimisation and long build times.

Runtime dependencies are pinned with exact versions rather than ranges: astrid-sdk at =0.7.1 with the derive feature, and astrid-core, astrid-crypto, astrid-types, and astrid-uplink all at =2026.10.1. Other dependencies are looser, with axum 0.8, clap 4.6, tokio 1, serde 1.0, toml 0.8, uuid 1.22, blake3 1.8.5, and fs2 0.4. Members cover apps/adaptive-shell, crates/unicity-aos-bootstrap, crates/aos-mcp-broker, and 27 capsules from capsule-agents through capsule-users.

Licence deserves a note, because the two statements do not match. The workspace package declares MIT OR Apache-2.0 and the repository carries both LICENSE-APACHE and LICENSE-MIT, while the project is published as Apache-2.0. The last push was on 2026-10-22, following releases 2026.10.0-rc.7, 2026.10.0 and 2026.10.1 in October 2026.

Forge ships a meta-harness skill, and --target-principal splits operator from target

The building story is Forge, which AOS treats as OS construction tooling. A fresh agent is expected to inspect the running system, learn the capsule model, find a real capability gap, and then build and verify a least-privilege capsule. Forge also installs the meta-harness skill, which teaches an agent to treat its instructions, memory, skills, harness code, tools, capsules, traces, and evaluations as an improvable user-space world, and to reach for Forge when new code is the right fix. The world model and research loop are written up in docs/meta-harness.md.

Principals have their own provisioned environments, while an authenticated operator manages the installation. Keeping the operator separate matters more than it looks when the operator holds broader authority than the target should. The same principle runs through aos mcp serve, where the principal is a configured argument instead of an inherited session.

Both daemon paths apply the enforced Community Edition distro.

Editorial conclusion

Adopt AOS Community Edition when you want to own the whole product surface and accept that its eight aos verbs move with a pinned runtime, so an upgrade is a coordinated event rather than a package bump. Before you commit, note that the macOS support notes say native execution on versions 11 through 15 is untested, so verify release/MACOS-SUPPORT.md against the oldest machine in your fleet.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. unicity-aos/aos-ce on GitHub