octos denies unsafe Rust and lists 39 workspace members

The repository description is a support message

The one-line summary on the repository page reads as a title, then a divider, then a user facing error.

The first part names the project and calls it agentic operating systems. After the divider comes a message about an agent not replying, with the remedy spelled out: run the login command for a provider, or export that provider's key as an environment variable, or add the key in the dashboard settings.

So the field that every search result and every repository card would show is not a description of the software but a piece of interface copy from a failure state, including the three alternative fixes for it. Nothing in the readme itself claims the project is an operating system; the readme calls it an embeddable agent harness kernel written in Rust, and the description is the only place the larger phrase appears.

The rest of the framing is consistent and unusually clear about who the reader is. A section near the top asks whether you are looking for a coding agent to use, and if so points at two separate client repositories, a terminal client that provisions a compatible local runtime on first launch and a browser client with its own getting started guide. The page then says this repository is for developers embedding, extending or integrating the kernel.

Three release candidates of one version, two on the same day

The three most recent tags are all the same version with a different candidate number: rc.11 dated 2026-09-06, then rc.12 and rc.13 both dated 2026-09-24. There is no stable tag among them.

The workspace manifest agrees, declaring its version as the thirteenth candidate of 2.0.3. So the three releases are three re-releases of one version number, which is how a project distributes a moving target without ever calling it stable.

The rest of the workspace metadata is conventional: a workspace resolver set to the second edition, the 2024 edition language level, a minimum compiler of 1.85, a single authors entry naming the octos team, the Apache-2.0 licence and the repository address.

The manifest also lists thirty-nine workspace members. The readme's crate table has seven rows, and they cover the core, the agent, the memory store, the model layer, the plugin layer, the pipeline and swarm pair, and the bus and CLI pair. That leaves seventeen further named crates in the manifest with no row in the table, among them a sandbox, a fleet and a fleet worker, a store, a server, a workflow crate, diagnostics, research, an embedded model runtime, a services crate and a bridge crate.

Fifteen of the members are skills rather than infrastructure: fourteen under an app skills directory and one under a platform skills directory.

OUP is a JSON-RPC contract, and the runtime keeps the state

The protocol boundary is the design decision, and it is described precisely enough to implement.

OUP, the Octos UI Protocol, is a JSON-RPC 2.0 interface for applications and for agent controllers. It carries requests, responses and typed runtime events over either WebSocket or newline delimited standard input, and local adapters can also reach the dispatcher in process. A WebSocket client connects to a path under the host's own API surface using that host's authentication settings, and request identifiers are strings.

Feature negotiation differs by transport and the page is exact about it. Standard input clients send a hello message. WebSocket clients ask through either a request header or a query parameter, with the same name in both cases. Then a client queries a configuration method to discover which methods a runtime actually supports, and chooses its controls and event formats from what is advertised.

Ownership is the other half. The runtime owns conversation history, execution state, compaction, permissions and committed results; clients render or act on that state rather than holding it. The five step controller flow follows from that: negotiate and query capabilities, open a scoped session with an identity the runtime confirms, start a turn with a fresh identifier and note that the acknowledgement only means the turn was accepted, then observe message, tool, task and progress events and use the steering, interrupt, approval and question response methods, and finally coordinate peers and recover.

Unsafe Rust is denied, so password input is a dependency

The workspace lints table contains one line, and it is absolute: unsafe code is denied.

That single setting is explained in the dependencies block, where a comment records an issue number and states that interactive secret input needed an echo free terminal wrapper, because the deny blocks a hand rolled termios implementation. The dependency chosen is a password input crate pinned to a major version:

cargo build --release -p octos-agent

So the rule is not decorative. It is the reason a specific third party library is in the dependency list, and it means the project cannot reach for a low level terminal crate if that crate would require unsafe code. For a kernel that executes shell commands and touches the filesystem, that is a defensible position to take in the manifest rather than in a policy document.

The compiler requirement is 1.85 while the container build uses a newer toolchain image, so the declared floor and the build environment are not the same thing. The minimum is what an integrator is held to; the image is what the project's own builds use.

The Docker dependency cache lists nineteen manifests by hand

The container build keeps its layer cache by copying the lock file, the workspace manifest, and then one line per crate manifest, followed by a block of commands that creates an empty source file inside each of those crates.

The comments say what the steps are for. The manifests are copied so the dependency layer can be cached, and the stubs exist so a library crate gets an empty library file and a binary crate gets an empty main file. Two dozen lines do it, one per crate, each writing an empty file after making its directory.

The cost is that the list is a second copy of the workspace membership. A new crate is not picked up automatically; its manifest has to be added to the copy block and its stub has to be added to the file creation block, in the right place, or the cached layer will not include it and the build will resolve differently from a local one. That is a maintenance obligation a build tool would otherwise handle.

The base stage is Alpine with three packages added, and the runtime of the build is a Rust toolchain image rather than a slim distribution, so this Dockerfile is a development path rather than a small production image.

The local server describes itself as a password-free login

The Makefile is small and its help text is the documentation. Six targets are offered, and the comments beside them are what a reader sees.

The first creates a project-local configuration file by running the CLI's init command with the current directory. The second starts the local API server, passing the feature set, the working directory, a data directory, a host that defaults to loopback, a port that defaults to 50080 and a flag whose default is written as solo. Its comment is the line that matters: the server is described as running with a password free local login by default.

That is a reasonable default for a server bound to the loopback interface and a bad one to inherit into a deployment. Nothing in the Makefile forces the host value to be changed, and the port is a plain number with no accompanying authentication setting.

The remaining targets build the two browser bundles. The dashboard target runs a shell script to build an embedded admin area. The web target first initialises a git submodule for the browser client and then builds the embedded application area, so a fresh clone without submodule contents cannot produce the web build. A combined target does both, and a development target builds the assets and then starts the server. The test target is a single workspace test run.

A test output file and a fix writeup sit at the root

The root is wide, and several entries look like they were left there after answering a question.

There is a file at the top level that looks like captured output from a peer test. There is a Markdown document whose name describes a timeout fix for the deep research feature. There is a text file about self hosted runners. There is a changelog generator configuration sitting next to the changelog it generates. There is a Homebrew formula directory. There are two documentation books, one in English and one in Chinese, as separate trees.

Alongside those are the project's own configuration: a directory holding the configuration the CLI writes, and a workspace configuration file, both committed. A model catalogue sits at the root as a single JSON file. A Nix flake with its lock file coexists with the Makefile and the compose file, so there are three build descriptions. There are two agent instruction files with different names, one of them the tool-specific name, plus a spell checker configuration.

The examples directory holds three named cases, a bridge configuration, a harness event, and a messaging network service configuration, which suggests the protocol is expected to be exercised against real external systems rather than a mock.

Editorial conclusion

octos is worth reading if you are building an agent into an existing product and want the execution loop, memory, tool layer and sandboxing to be a library you link rather than a service you host, because the split between the kernel and the protocol is stated plainly and the protocol surface is specific enough to implement against. Three things to weigh. The credential and route catalogue is broad, with fifteen skill crates in the workspace and app bridges for mail, a messaging network and a smart home, so review what a given deployment actually enables. The local development server describes itself as a password-free login, which is fine on loopback and is not what you want exposed. And the release tags are all candidates of one version number, so pin a git revision rather than a tag if you need the version you tested to be the version you get.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes