The daemon keeps agent work alive
CompozyOS puts a persistent runtime around agent command-line tools. Sessions, tasks, scheduled Loops, approvals, artifacts, memory, and permissions belong to a home-scoped daemon instead of one terminal process. Close the browser or CLI and the daemon retains the run. A web client, structured CLI output, HTTP with server-sent events, Unix sockets, MCP, and native tools can all address that state.
This is useful for people who have outgrown a folder of shell scripts around Claude Code, OpenClaw, or Hermes. An agent definition can live globally or inside a workspace, with an AGENT.md and optional local mcp.json. Markdown task files use typed frontmatter, while cron schedules, webhooks, and triggers start durable work. Compozy Network adds peer discovery, typed messages, delegation, and completion receipts.
The local-first claim has a concrete boundary. Runtime state uses a Go daemon and SQLite-backed stores on the operator's machine. Calls to configured model providers and extensions can still cross that machine. Remote access goes through a Gateway that pairs devices and exposes only enabled surfaces, so operators remain responsible for what they publish.
v0.3 beta is a migration, not an update
The warning near the top of the README deserves more attention than the feature list. The v0.3 line is beta. Version v0.2.15, released July 17, 2026, is deprecated and receives only critical fixes on a legacy branch. Homebrew continues to install that older line until v0.3.0 becomes stable. The npm path requires the @beta tag, and go install ...@latest also resolves to v0.2 unless you supply an explicit beta release tag.
Existing users must read the migration guide. The new runtime imports task files into durable tasks and executes them through Loops; it does not restore the v0.2 tasks run pipeline. Configuration ownership changed too. Global defaults live in ~/.compozy/config.toml, workspaces can override supported fields, and command flags win over both. Credentials and provider homes have separate rules, so copying an old home directory is not the migration plan.
The transition is moving quickly. The repository was pushed on August 25, 2026, and open work that day included the v0.3.0 release, runtime routing, and profile hardening. Its 22 open items combine issues and pull requests. This is an active beta queue, not an abandoned stable product.
What happened when we ran it
Our sandbox installed 1,581 packages with Bun in 91 seconds. Dependencies occupied 1,918 MB, which is a serious development footprint for a checkout of 308.4 MB. The monorepo contains 16,573 files and about 2,515,679 lines of source across Go and JavaScript workspaces.
The build ran for 18 seconds before codegen-check failed. Its Go parser reported that go.mod contained an invalid Go version, 1.26.4, where it expected a form such as 1.23; it also reported an unknown tool directive. The task summary showed 2 successful tasks out of 5 before exiting 2.
Tests stopped after 12 seconds at the same codegen-check boundary. Two cached tasks completed, but the Go module errors prevented the wider test target from running. Those messages do not prove that Compozy's application tests fail. They show that commit a7a8970 could not pass its repository gate with the Go parser present in our fresh Node 22 sandbox. Source contributors need the exact supported Go and Bun toolchain before make verify becomes meaningful.
Extensions trade convenience for a trust decision
The extension system is one of CompozyOS's better ideas. A Go tool provider can be initialized, run in development, and invoked through a generated name. Code declares the tool, while the build step produces its manifest. Resource-only extensions can use a hand-written extension.toml without executing code. SDKs exist for npm and Go, version-matched to the daemon.
The daemon handles discovery, enablement, provenance, lifecycle, hooks, logs, reloads, and workspace boundaries. That gives extension authors a defined contract and gives operators one place to inspect status. It does not make third-party code safe. Enabling an executable extension is still permission to run code, and an agent able to invoke it may reach whatever capabilities the extension exposes.
Skills follow a similar scope model. Global and workspace resources can be listed and inspected through structured commands. For Claude Code users, this is more manageable than copying loosely tracked prompts and MCP configuration between repositories, provided the team treats inspection and permission policy as normal operations.
Current Loop faults limit unattended use
The open issue tracker shows why the beta label matters. Issue 479 describes a route-not-taken task remaining runnable and deadlocking a downstream claim. Issue 480 reports a goal-session cleanup payload conflict that prevents an action from settling. Issue 451 describes a daemon crash loop after a beta update changed a Loop run's executed-definition digest. These reports concern persistence and recovery, the exact behavior CompozyOS is meant to own.
None of that makes the architecture pointless. It sets the right adoption level. Run a beta beside work you can reconstruct, inspect state after failures, and keep migration notes for every update. Do not let the first experiment become the only scheduler for releases or production changes.
CompozyOS is most convincing for an individual or small technical team already juggling several agent CLIs. The shared state and supervision model can replace a surprising amount of glue. Teams that mostly need predictable webhooks should use n8n, while application developers who need strict workflow recovery should examine Temporal. Compozy earns a trial now, but v0.3 stable is the sensible line for broader dependence.