更新日志

A Hermes or OpenClaw turn no longer fails with “produced no output” the moment its sandbox wakes from a pause.

The daemon’s inactivity budgets now count only the time the machine was running. A turn whose sandbox slept mid-run keeps its whole budget after the sandbox wakes, instead of finding it already spent by the pause.

The daemon now proves which model provider served an OpenClaw or Hermes turn, so those turns are priced on the route that actually answered them.

For each turn the platform sends a one-time challenge. The daemon follows the route the runtime used: for OpenClaw, the provider the gateway’s transcript names and its entry in openclaw.json; for Hermes, the model section of the config.yaml the ACP child loads and the provider key in its environment. It answers with an HMAC keyed by that provider’s key, so the key never leaves your machine. A route it cannot resolve the way the runtime would gets no proof and a reason instead: profiles, credential pools, secret-manager sources, a config edited during the turn, or a resumed Hermes session the daemon did not see created.

The daemon now starts again after a restart that left its old pid file behind, and stopping it never signals some other process.

A daemon killed without cleaning up leaves its pid file in place, and after the machine or its container restarts, that number can belong to another process. mf daemon start used to take that process for the daemon and exit with “daemon already running” every time, until the file was removed by hand, and mf daemon stop signalled it. Both now treat a pid file written before the process holding its pid started as stale: the daemon starts, and stop leaves the other process alone. mf daemon status and mf doctor report the daemon the same way.

The Update Center comes to the terminal, usage reports print tables and check their options, and an agent-to-agent call that the peer hands back as still working is followed to its answer.

mf updates lists what the web’s Update Center lists: the mf CLI and herdr on your computers, sandboxes and cloud computers, each runtime’s framework, the CLIs a sandbox ships, and your agents’ skills, with the version each is on, the one it would go to, and whether it can run from here. mf updates apply runs them in the Update Center’s order, at most five computer updates a minute, and reports each as updated, pending until the machine’s sessions finish, or failed. mf updates versions shows the versions you can install. mf sandbox list shows each sandbox’s CLI version and points at mf sandbox update or mf updates apply --kind cli when one is behind.

mf usage prints tables, and on its own runs summary. The JSON is unchanged but no longer the default: a script or agent that reads mf usage output must pass --json. Options are checked before anything is sent, and a bad one exits 5: --bucket takes hour or day, --limit is a whole number in range, and --from and --to take a date or a date and time, read as UTC unless they name a zone. Inside an agent runtime, mf --account usage reads the whole account. mf mcp catalog list and mf skills discover check --limit the same way.

mf a2a send follows a task the peer hands back working at its blocking limit and prints the answer when it finishes, within the same --timeout. Past the deadline it exits 1 with the command that keeps following the task. A task that ends failed, canceled or rejected prints its reason and exits 1.

mf update reports failures like every other command and takes --json: a network failure exits 2 and names the host, and a bad --channel or --to exits 5 before anything is fetched. A 401 for a token of the wrong kind says the call needs a login session or a full-access token. A daemon update that waits for its sessions now retries a failed download instead of giving up, and a sandbox update the daemon defers completes; the runtimes page and mf sandbox update show how many sessions it is waiting for.

Errors now say what went wrong and exit with the code their kind promises, every list prints a table with a header, and agent-to-agent calls carry files and stream to the end from the standalone binary.

A mistake on the command line exits 5 with invalid_usage wherever the command notices it, and an @file that cannot be read names its flag. mf channels test and mf channels register exit 1 when the check fails, as mf doctor does. A plan limit or quota no longer points at your token’s scopes: each code gets a hint with the numbers, such as 2 of 2 on the Free plan, and what to free up, and --json passes its details through.

Every list command prints an aligned table with a header row; --json is unchanged and stays the format for scripts. --help marks the options a command cannot run without, mf channels create --config defaults to {}, and the new mf channels sessions get shows one channel session, archived ones included. Switching to a deleted session now fails with a hint instead of reporting success.

mf a2a send --stream no longer hangs in the standalone mf, and --input-file reaches a Manyfold peer, which reads the file in its workspace. A2A failures exit by kind: an endpoint that does not resolve or answer exits 2 and names it, a peer you hold no grant for exits 4, and a refusal the peer names, such as a sandbox CLI too old for files, keeps its code and hint. Adding a caller that already has a grant suggests --replace-existing.

An agent can now be created, talked to and set up from the terminal the way the web app does it. Creating an agent picks its model and its sandbox, a conversation runs at the command line, automations take their schedule the way you would say it, skills install by name or publish from a local folder, and an agent’s MCP servers are managed per scope.

mf agent create --model-provider binds the agent to Manyfold managed models, to your own subscription or to a saved provider, --model picks one of the provider’s tested models, and --sandbox adds the agent to a sandbox you already have. Progress names each step, and running the same command again after Ctrl-C attaches to the create already under way. It no longer reads keys or models from environment variables: pass the key flag, with - to read it from stdin. --provider-id is now --runtime-provider, and --model replaces the per-framework model flags.

mf agent send sends one message and prints the reply, with files, thinking and a Ctrl-C that stops the turn on the server; mf agent chat holds the conversation at a prompt. mf agent update --model sets a coding agent’s model from its next turn.

mf automations create builds its schedule from a preset such as daily or weekly, timed with --at, in this machine’s timezone. mf automations run --wait follows the run’s reply, and mf automations result prints the full reply of the latest run.

mf skills install takes a skill’s name, and mf skills library publish puts a local skill folder into your library and onto the agents that have it. mf mcp adds, installs, lists and removes an agent’s MCP servers and writes them to its machine; mf mcp pull first reads back servers added on the machine itself.

mf sandbox list, delete and update show, free and update your sandboxes, and mf model-providers list and test show which providers can serve a framework, with which models.

Runtime-local model lists offer the newest models: GPT-6 Sol and GPT-6 Luna for Codex, and Opus 5, Opus 5.5, Sonnet 5.5 and Fable 5.1 for Claude Code. GPT-5.4, GPT-5.4 Mini and GPT-5.2, which Codex itself retired, are no longer offered.

Signing in no longer needs an interactive terminal: mf login --print-auth-url prints the sign-in URL and exits, and mf login --auth-code completes the sign-in with the code shown once you approve it. Nothing is stored in between. A daemon that is waiting for its current work to finish before it updates now keeps its first deadline, so asking it to update again no longer puts the update off.

The daemon no longer keeps a command’s input on disk. File operations and terminals on a hosted machine accept the folders Manyfold vouches for. No folder, whether vouched for or registered, reaches the daemon’s own settings, where its tokens live, beyond its workspaces and sign-ins. A file too large for a single message is written in parts, and it replaces the destination only once it is complete and its checksum matches.

mf agent storage-usage reports the workspace and config sizes of an agent on a sandbox from the sandbox’s last storage measurement, with the time it was taken in measuredAt, so the sizes are there while the sandbox sleeps instead of unknown. The agent help for mf agent and mf sandbox says where the sizes come from.

The daemon account inspector now reads Antigravity CLI subscription quotas from Cloud Code and returns sanitized model-level usage windows, including reset times, alongside the existing Codex and Claude Code subscription usage. Credentials remain on the host and are never included in the report.

A turn now carries the directories it may work in. The platform sends them with each exec.start, and the daemon admits them for that exec only, so an agent whose workspace sits outside the managed tree (a coding agent that shares a sandbox with another framework) no longer needs a separate registration round trip before every turn. The daemon advertises this as exec.roots.v1; a platform that needs it on an older daemon asks for an update instead of failing mid-turn.

One machine is one host, one host runs one mf daemon, and a runtime is one framework on one host. A daemon registers onto its host and scopes its local stores by the host id; on a stateful sandbox or a cloud computer the platform brings the daemon up itself.

mf daemon status prints the host id, whether the machine is a self-owned computer or hosted, the host status and whether the daemon is online, and lists each runtime with its install status and availability. mf runtime get and mf agent get print availability, host, provider and power state in place of the sprite, namespace and ingress lines, and mf sandbox storage-usage shows each machine’s power state.

mf agent create --account-id becomes --provider-id (admin only), which places a new sandbox on a runtime provider. mf runtime delete no longer tears down the machine or its agents: it is refused while agents still use the runtime.

The daemon detects Antigravity CLI (agy) and reports its version. An Antigravity CLI agent can use agy’s own sign-in on the machine, a Google account or a Gemini API key, as its Local model source; the model picker then lists the models agy models offers there, including a Google AI plan’s Claude and GPT-OSS models.

mf agent create --framework antigravity-cli creates one, with --google-api-key for a platform key and --agy-model for its model.

mf daemon hooks install also installs agy’s session hook, a manyfold-session block in ~/.gemini/config/hooks.json next to any other blocks there. A conversation started in a Manyfold terminal joins the chat list when the terminal closes, and leaving agy hands a resumed conversation back to the chat. agy conversations can be handed to herdr 0.9.1 or newer.

The Manyfold operator guide now supports both platform-managed agents and external Claude Code or Codex sessions. The shared manyfold-cli-usage skill includes identity-aware authentication, workbench links, and result verification. External coding agents can install it through the Manyfold plugin.

OpenClaw turns wait for a booting gateway before starting. Ask mode uses OpenClaw’s guarded permission mode, preserving command approvals and the selected model; an unsupported gateway configuration fails explicitly.

A daemon can start even when a discovered coding CLI or herdr binary cannot be executed, such as after an interrupted installation. Such binaries are reported without a version, and herdr update failures are reported directly.

A2A send deadlines now include discovery and streaming. Remote cancellation, input and authentication prompts, and HTTP error details are preserved.

A daemon now needs Manyfold CLI 4.6.1 or newer. The API refuses registration, heartbeats and connections from an older daemon, and mf doctor and the daemon’s refusal message name that minimum. A daemon that launchd or systemd starts against the official API updates itself once it is idle; one started by hand needs mf update and a restart.

The runner no longer admits a framework home directory outside the core set by default. The platform registers such a framework’s home with the runner before a turn, so its agents keep working.

mf a2a send --stream and mf a2a tasks subscribe now print a peer’s answer once, when the stream ends, instead of writing each chunk as it arrives. A peer can replace an artifact it has already sent, and text written to a pipe cannot be taken back, so the final text is what you get. Status lines still go to stderr as the task progresses, and --json still emits every event live.

The daemon knows a new startup method, container, which the Manyfold pod host image sets. Under it the daemon accepts updates from the platform and restarts into the new version, while its own auto-update stays off.

In that mode the daemon also keeps the services of the frameworks installed on the machine running: it starts them, restarts one that crashes, with a backoff, and keeps them running across its own updates.

Hermes turns carried by the daemon no longer stall at startup.

mf agent help now describes --framework by example. It names the core frameworks (openclaw, hermes, claude-code, codex, gemini-cli and pi) instead of presenting a closed list, because an edition of the platform can register frameworks of its own.

Pi (pi.dev) joins the coding CLIs the daemon runs. The daemon detects pi and runs Pi agents on your computer. It reports what Pi’s own sign-in can use there — its auth.json sign-ins, keys and the models pi --list-models offers — so an agent can run on it. A runtime account for Pi signs in by running pi and /login in that account’s own agent dir. mf daemon hooks install adds Pi’s session hook, an extension Pi loads on its own, so a Pi TUI opened from Manyfold reports its session like Claude Code and Codex do. herdr can start Pi for a handed-over conversation. The daemon now reads Pi’s session files under ~/.pi, which listing, viewing and syncing Pi sessions need. mf agent create --framework pi takes --pi-api-key with --pi-provider.

mf doctor finds what is wrong with a machine’s mf setup and says how to fix each problem. It checks the install and every profile on the machine: the sign-in and API (an unreachable deployment, a URL that is not the API, a rejected token and why) and the daemon (its registration, process and autostart unit, a daemon still running an older binary than the one on disk, and why it is offline). It exits 1 when a check fails, and mf doctor --json gives the same report for scripts. A daemon the API turns away (a revoked, deleted or too-old machine) no longer reconnects every second: it logs why and retries less often, down to once every 15 minutes. Rejected heartbeats are logged, autostart units keep MF_CONFIG_DIR, an invalid MF_HTTP_TIMEOUT is an error, and mf daemon status checks the registration the way mf daemon start does.

The daemon can hand a chat session to herdr. When herdr is on the machine (on PATH or in ~/.local/bin), “Switch to herdr” in the web opens the conversation’s Claude Code or Codex TUI in a herdr pane, with a workspace per agent and a tab named after the conversation. The conversation comes back to the web by itself when the TUI quits or the pane closes. Handing the same conversation over again reuses its tab, and a daemon that restarts adopts the panes it opened, so their conversations stay handed off. A platform runner starts herdr server itself inside its sandbox. The daemon reports herdr’s version so the Update Center can show and upgrade it, mf daemon status counts the terminals running in herdr, and mf daemon doctor says whether herdr is available. A plain terminal closed from the web now hangs up its shell instead of leaving it running.

The daemon now reports the coding CLI’s own session to the platform through Claude Code and Codex session hooks, installed with consent at mf daemon register / mf setup (--no-hooks to skip) and managed with mf daemon hooks install|uninstall|status. Terminals opened from the workbench belong to the daemon: a dropped tab reattaches to the same shell with its screen intact, and mf daemon status shows the terminals kept and attached. Behind MF_DAEMON_EXEC_FILES=1 (macOS / Linux preview), chat-turn execs run detached through files and survive a daemon restart, profile lease included; mf daemon stop --keep-execs leaves them for the next daemon, mf daemon doctor reports whether execs would survive, and a manual install can take a remote upgrade by handing off to a successor it watches.

Sandbox storage reporting now uses explicit scopes and byte units. mf sandbox storage-usage reports the current sandbox by default and accepts --account for an authorized account-wide report. Agent JSON replaces the ambiguous storageBytes fields with nullable workspace measurements and returns an explicit { scope, agents } envelope. Upgrade the API and CLI together.

Executions now own their temporary settings and isolated process tree until cleanup finishes. Cancellation stops the full process tree and removes the temporary settings before the final execution acknowledgment on every supported platform.

Daemon startup now logs before inspecting the user’s shell and bounds every shell probe to three seconds. A timed-out probe and its process tree are stopped, while the current PATH and the directory containing the running executable remain available as fallbacks.

On Windows, temporary file-sharing denial no longer makes ownership metadata replacement fail immediately. The CLI retries only the expected replacement errors for a bounded interval, keeps the previous target intact, and retains the kernel ownership lock throughout publication. Persistent permission errors still stop startup with an error.

An execution now remains active until its runtime-auth profile lease has been released. Immediate work on the same profile can acquire the lock after the first execution completes, including when spawning, streaming, cancellation, or cleanup fails.

Darwin binaries are finalized with an ad-hoc signature and verified before and after packaging. This confirms artifact integrity and the ai.manyfold.mf identifier; it does not provide Developer ID notarization or guarantee that macOS privacy grants survive an upgrade.

The daemon now admits one process per profile. Concurrent foreground starts stop before opening a connection or sending heartbeats, and a live control socket prevents a second daemon from starting even when its PID file is missing. Kernel ownership is recovered after a crash, including container restarts that reuse PID 1.

Repeated starts and reconnect callbacks keep one connection attempt active. Events from an older socket cannot close its successor or remove a newer RPC’s cancellation handler. Connection diagnostics can report the client process identity without changing the existing authentication contract.

Let active work finish and close any duplicate foreground copies from an older CLI. Run mf daemon stop, mf update, then mf daemon start for the selected profile. Keep its registration and workspace data. See the self-owned computer guide for profile-specific commands and recovery guidance.

The CLI now requires the current Manyfold API contract. Upgrade the API before upgrading the CLI when running a self-hosted installation.

mf whoami uses /api/auth/whoami exclusively. A missing endpoint fails with HTTP 404 instead of retrying /api/auth/me and constructing a legacy identity. Login and setup continue to use their existing account endpoint.

Structured API errors must contain a nested error object. Legacy top-level code, message, and details fields are no longer interpreted as error metadata. When an error response does not follow this contract, the CLI uses the HTTP status and does not print the unparsed response body.

Existing profiles, runtime credentials, and current identity kinds remain valid. See the self-hosting upgrade instructions before crossing older API migration boundaries.

A2A uses one command to send work and one to inspect peers and running tasks. The deprecated call, stream, and peers aliases are removed. Update saved scripts and Agent instructions before upgrading:

status --json returns an object containing peers and inflight arrays. Scripts that read the previous peers --json array must read the peers field. The send --async and tasks commands retain their existing behavior.

Existing daemon registrations, runtime credentials, profiles, and workspaces remain valid. The HTTP peer-list endpoint is unchanged.

The daemon can hold an API key as a runtime account: an api-key auth profile keeps the key in that profile’s own credential context on the host (<view>/api-key, mode 0600) and injects it as the vendor’s environment variable for runs bound to the profile; sign-in is refused for such a profile, and signing out removes the key. Hosts advertise this as the auth-api-key.v1 capability; an API that does not see it refuses the create instead of storing the key elsewhere.

account.inspect accepts a usage flag so the API can re-read the sign-in without asking the vendor for usage again; the previous behaviour (usage included) is the default.

Existing daemon registrations, profiles and workspaces remain valid.

The CLI retires legacy turn-timeout and update-channel aliases. Update channels are now stable and dev; scripts using --channel staging must switch to --channel dev. Daemon turns use separate execution and first-response budgets.

Existing daemon registrations, profiles and workspaces remain valid. API 5.0.0 requires every daemon to run CLI 0.34.0 or newer. Self-hosted API upgrades must first run API 4.0.0 and complete the configuration and data migration preflight described in the self-hosting guide.

Daemon WebSocket connections now send credentials in the Authorization header, keeping bearer tokens out of connection URLs. Existing daemon registrations, profiles and workspaces continue to work.

For self-hosted deployments, upgrade the server to Manyfold v0.5.0 (API 1.1.0) or newer before updating the daemon. Reverse proxies must forward the Authorization header when upgrading WebSocket connections.

Daemon connection-success logs no longer include the authentication URL or its bearer token. The daemon continues to authenticate with existing servers.

The CLI now uses browser login and runtime permission requests after retirement of the device-code grant flow.

Use mf login for browser login and mf auth ensure --scopes <list> when an agent needs another permission.

External A2A client grants continue to work with their existing target and revocation rules.

A computer or sandbox can now hold more than one vendor sign-in, and each agent picks which one it runs under.

• Added accounts live beside the host sign-in, not on top of it. From the runtime page you can add a second Claude Code, Codex or Gemini CLI account, sign it in from a terminal that opens inside that account’s own credential store, and sign it out or remove it later. The machine’s own sign-in is left exactly as it was.
• Switching auth never forks configuration or transcripts. Each added account keeps only its credential files; sessions, history, config and codex’s state databases stay in the native CLI home, so resuming a session works the same whichever account it ran under.
• Agents run under the account they are bound to. Chat turns, the agent terminal and the model-capability probe all run inside the bound account’s context, with the machine’s ambient vendor keys stripped. Two agents on the same account take turns rather than refreshing the same token twice.
• An older daemon refuses instead of guessing. A machine that cannot honour an agent’s account binding — including this CLI’s predecessors — declines the execution rather than answering with its native sign-in, and the web UI points at the update.

No command, flag or output changed in this release; the new behaviour is advertised to the API as the auth-profiles.v1 and auth-context.v1 capabilities.

An upgrade on a sprite no longer risks losing an agent’s stored identity.

• Legacy identities are migrated before anything cleans up. Older sprites kept per-agent identity in the shared shell profile. Upgrading the CLI or a framework rewrites that profile, so anything still living there was lost. Both upgrade paths now move a legacy identity into encrypted storage first and only then clean the profile, which makes the upgrade safe to run on a sprite that has never been migrated.

No command, flag or output changed in this release.

mf channels create can now create an iMessage channel.

• --provider imessage. The provider list accepts imessage, so an iMessage channel can be created from the CLI the same way as any other. Apple publishes no iMessage API, so the channel talks to a BlueBubbles server you run on your own Mac: pass its URL and server password as the credentials, then run mf channels register to read the server’s version and install the inbound webhook automatically.

No other command, flag or output changed in this release.

When the platform enables it, the daemon can now run an OpenClaw chat turn over the Agent Client Protocol against the OpenClaw gateway already running on your machine — no mf command, flag or output changed. The daemon discovers that gateway from your own OpenClaw config, never starts one, and never sends its token off the box. Approval prompts and per-message model choices flow through the same gateway, and a turn interrupted by a reconnect is recovered rather than lost. The previous local path is unchanged and still used when the feature is off.

No command, flag or output changed in this release.

Internally, the daemon’s ACP client now shares one implementation with the platform’s: the decoders that read an agent’s streamed events, permission requests and session state moved into a common package, so a turn you run locally and a turn replayed after a reconnect are read by exactly the same code. Behaviour is unchanged in both directions.

mf channels create can now create a Google Chat channel.

• --provider googlechat. The provider list accepts googlechat, so a Google Chat channel can be created from the CLI the same way as any other. Pass the service account JSON key as the credentials, then run mf channels register to capture the authentication audience and activate the channel.

No other command, flag or output changed in this release.

Self-hosted Codex agents can now be pointed at GPT-6 Astra, and at the two reasoning levels above Extra high.

• GPT-6 Astra in the model picker. When an agent runs on your own machine and your own Codex sign-in, the daemon reports the model catalog it can offer; that list now includes gpt-6-astra, so the model shows up in the agent’s model settings without waiting for a platform provider to carry it.
• Maximum and Ultra reasoning. The daemon also reports the reasoning levels, which now go up to max and ultra. Which of them a given model actually accepts is decided per model — Astra reaches ultra, GPT-5.6 Luna stops at max, and GPT-5.5 and older stay at Extra high — so the picker will not offer your agent a level its model would reject mid-turn.

Nothing changes for agents that use a platform model provider, and no command or flag changed in this release. Run mf update on daemon hosts to pick it up.

Switching a chat session to Terminal can now drop you straight into the coding CLI’s own interactive interface, resumed on that same conversation, instead of at a bare prompt. The chat view and the TUI become two front ends over one session, and this release is what lets a self-hosted daemon do it.

• New pty.command capability. The daemon can open a terminal that runs a given command as the shell’s argv rather than typing it into the pty, so there is no guessing whether the prompt is ready yet — and quitting the TUI leaves you in the interactive shell you would otherwise have had. A daemon on an older CLI says so instead of opening a plain shell under a UI that promised a resume.
• Only the session id travels. The browser sends the chat session’s id and the API looks up that session’s own recorded CLI reference to build the argv, so no caller chooses what runs on your machine.
• Both directions stay in sync. What you say in the resumed TUI is folded back into the chat view, and messages sent from the chat show up in the TUI. Claude Code and Codex are supported; Gemini’s resume takes a session index rather than an id, so it opens a normal shell.

Run mf update on daemon hosts to pick up the capability.

The daemon can now tell the runtime page who its coding CLIs are signed in as, and what those accounts have used. Open a Claude Code, Codex or Gemini CLI runtime under Settings → Runtimes and the new Account section shows the signed-in email, organization and plan, the sign-in status, and the vendor’s usage windows with their reset countdowns.

• New account.inspect capability. The daemon reads the CLI’s own credential files and calls the vendor usage endpoint itself, so the token never leaves your machine — only the response and non-secret identity fields do. Daemons on older CLIs show an “update the CLI” prompt on the runtime page instead of a probe failure.
• Sign in from the runtime page. When nothing usable is signed in, a “Sign in” button opens a shell on the machine inline and starts the CLI’s headless sign-in (claude auth login --claudeai, codex login --device-auth, NO_BROWSER=true gemini); closing it re-checks the account. The shell carries no agent environment and no Manyfold token.
• macOS note. Claude and Gemini keep their tokens in the Keychain, which the daemon deliberately does not read, so those runtimes show the signed-in identity without usage. Codex keeps a file and shows both.

Run mf update on daemon hosts to pick up the capability.

Hermes chats grow up: tool outputs render, the model can be switched per message, and the new permission modes can route approvals to you instead of auto-approving everything. The daemon advertises two new capabilities — turn.hermes.options and turn.hermes.permissions — and the platform refuses, with a clear upgrade message, to send a model switch or an ask-mode turn to a daemon that predates them.

• Interactive permission approval for hermes. Pick “Ask for approval” or “Accept edits” in the chat composer and the agent’s permission requests appear as cards in the transcript; the daemon holds the turn open while you decide, denies safely if nobody answers within the timeout, and records the outcome durably so a recovered turn replays it exactly.
• Per-message model switching for hermes. The daemon applies the choice via ACP session/set_model after checking the session’s current model, so an untouched session costs no extra round trip, and reports the session’s model/mode state back to the platform.
• Hermes file edits stop being silently denied. The headless auto-approval now answers with an option the request actually offers; current hermes builds only advertise allow_once/deny on edit approvals, and the old hardcoded answer mapped to deny.

Run mf update on daemon hosts to pick up the new capabilities — older daemons keep working for everything except the new model-switch and ask-mode features, which are refused rather than silently degraded.

A maintenance release: the daemon reports one more capability, and nothing else changes.

• The daemon advertises model.credential-facts. Model inspection responses have carried per-framework credential facts for a while; the daemon’s hello and heartbeat now declare that capability explicitly, so the platform can tell which hosts report it without guessing from version numbers. Behavior is unchanged — no action needed.

Skill discovery now pages like the rest of the catalog, and a long-obsolete timeout variable finishes its migration.

• mf skills discover is paginated. New --sort featured|latest, --cursor and --limit (up to 100 per page, which is also the default — today’s catalogs still fit in one response). When more results exist, the command prints the next cursor as a hint on stderr; pass it back with --cursor to continue.

• --json output changes shape. It used to print a bare array of skill summaries; it now prints the page object — {"items": [...], "nextCursor": "100" | null}. Scripts that parse the JSON should read .items and follow nextCursor until it is null. Human-readable output now follows the catalog’s featured ranking.

• A2A_TURN_TIMEOUT_MS retires. If your deployment still sets this legacy env var, the API migrates its value into the A2A turn timeouts admin setting once at startup (an existing admin save always wins, and values outside the setting’s 30s–1h blocking / 24h async bounds are clamped and logged) — after that the variable is ignored and every boot reminds you to delete it. While cleaning house, the API also warns at startup for each legacy NCA_* / WEB_BASE_URL env alias it finds, and MF_CHAT_STREAM_FLUSH_MS / MF_TURN_ADOPT_REPOLL_MS are documented in .env.example.

mf update pulls the new binary.

The legacy device-code grant flow is gone. mf login is now only about authenticating your machine; capabilities live where they moved months ago.

• Removed: mf login --poll and everything that existed for it — --wait, --scopes, --for-agent, --limit-to-agent and --resume. The flow minted agent-scoped tokens through a device code you pasted into the browser; it was superseded by mf auth ensure --scopes <list>, which requests exactly the missing capability for the agent and sends its owner a consent link. Every message the old flow printed has pointed there for a while.

• Older binaries get an answer, not an outage. A pre-0.26 mf login --poll still reaches the API and is refused with the fix in hand: run mf update, then mf auth ensure --scopes <list>. Tokens the old flow already minted keep working unchanged until they expire.

• The pending-login file retires with the flow. Poll-mode logins used to persist a pending request so the next mf command could redeem an approval after the process died; nothing writes that file anymore, and the automatic redemption that ran before every command is gone with it. A login pending across this upgrade (they live 15 minutes) is not redeemable — run mf login again. The upgrade also cleans up any leftover pending file on your machine the next time you log in.

mf update pulls the new binary.

The daemon now reports enough about your local sign-ins for the platform to tell a working one from an expired one, and mf model-config update --model stops discarding the model you pass it.

• model.inspect reports credential facts, not a guess. The daemon used to answer “are these credentials usable?” by checking whether a config directory existed — a readable ~/.claude counted as a working login, an auth.json that could not be parsed counted, and oauth_creds.json was opened without anyone reading the expiry_date inside it. It now reports what it found: whether a token is present, when it expires, whether a refresh token can renew it, and which third-party gateways ~/.codex/config.toml configures. The values themselves never leave your machine — only presence flags, timestamps, and the name of a provider’s environment variable.

• An expired sign-in is now reported instead of failing mid-turn. Because the facts carry timestamps, the platform re-derives validity against the current time rather than trusting a snapshot. A sign-in that has lapsed with no way to renew is surfaced before a message is sent, and signing in again on the machine clears it — the check re-runs before it refuses.

• Nothing is judged that cannot be judged. A macOS host keeps its Claude token in the keychain, which a background daemon must not prompt for, so that case stays permissive and unchanged. So does any daemon older than this release: it reports no facts and keeps working exactly as before.

• Fixed: mf model-config update --model <name> set the model. For an agent using its local config it reported success and then dropped the value, so the agent kept running whatever it ran before. The same fix reaches /model <name> in a connected channel.

• mf model-config get shows the models your CLI actually reported, which is what the web composer now offers as a picker for agents on the local-config source.

Existing daemons keep working unchanged; mf update pulls the new binary.

The update mechanism moves off the CDN and onto release manifests, and the pre-release channel is now called dev everywhere.

• mf update resolves a release manifest instead of a version file. The old path fetched a plain version string, then built the archive URL and a separate checksum URL by string concatenation — so the checksum could be served from a different cache generation than the bytes it described, and the storage layout was baked into every installed binary. A channel is now one manifest that names every artifact by absolute URL with its checksum: two requests instead of three, and the download location can move without reissuing binaries.

• The dev channel is ordered by commit. Consecutive dev builds share the same x.y.z, so version comparison called them identical and the channel could not tell “newer” from “different”. Builds now carry their source commit, and mf update follows it.

• dev is an update policy, not an environment. Both channels default to the production API; a dev binary simply installs newer code sooner, in its own dev profile. To work against a pre-production API, pin it at login with --api-url.

• New mf version. Bare output is identical to mf --version; --verbose and --json add the update channel, source commit, build time, platform target, install method and config paths — the things a bug report needs.

• Install from https://manyfold.ai/cli/install.sh. The installer reads the same manifests, so it no longer calls the GitHub API and is no longer subject to its rate limit. MF_CHANNEL=dev selects the pre-release channel and VERSION= pins any published build.

• Fixed: the daemon’s background auto-updater followed the channel its binary was built for rather than the channel you selected, so a machine switched to dev quietly drifted back to stable on the next check.

--channel staging still works as an alias for dev, saved preferences are migrated on read, and builds published as -staging. are still recognised as dev builds — nothing needs to be reinstalled.

Patch release for daemon enrolment on self-hosted deployments:

• mf daemon register now honors the API endpoint stored by mf login. The command resolves its endpoint the same way every other command does: an explicit --api-url wins, then the profile’s stored endpoint, then the channel default. Previously the stored profile endpoint was skipped, so a machine logged into a self-hosted API silently tried to enrol against the default endpoint and was told its daemon token did not exist.

Maintenance release with two housekeeping changes:

• Dev-channel endpoints are baked in at build time. Official release builds behave exactly as before, while builds produced without those endpoints — such as open-source builds — now clearly report that no dev update channel is available instead of pointing at a deployment-private host.
• Removed a stray MIT LICENSE file from the CLI package. The CLI’s terms are unchanged — Apache-2.0, as the repository’s root license states — the published tree just no longer carries two conflicting license files.

Maintenance release: internal cleanup of the daemon start path (removed a dead start-lock code path). No user-facing changes — commands, flags and daemon behavior are identical to 0.23.0.

This release restores interrupted turns on your own computers and runners, lets the daemon manage Claude Code’s user-level MCP configuration on your behalf, and retires a command that never worked.

Highlights

• Interrupted turns finish instead of restarting. When the connection carrying an OpenClaw turn drops, the daemon can reattach and complete the same assistant message rather than starting a second run. You are not charged for a duplicate model call, and cancelling a resumed turn stops the original work.
• Managed MCP configuration. The daemon can read and write Claude Code’s user-level ~/.claude.json for Manyfold-managed MCP servers. Only that exact path is accepted and never through a symlink, and older daemons are never asked to do it.
• Config files carrying secrets are written 600. File writes now honour an explicit permission mode, so generated config lands readable only by you instead of at the default permissions.
• Less local metadata retained. The daemon no longer records execution environment into its local stream metadata; connection tokens and platform identity travelled in that payload and nothing ever read it back.

Removed

• mf agent logs is gone. It was advertised in help output but never fetched or displayed agent logs. Nothing that worked before stops working.

This patch hardens the daemon-side stream recovery used when a self-owned computer or runner replaces its connection while a turn is starting.

Highlights

• Terminal results stay terminal. A completed resume probe is returned as the result instead of being mistaken for another connection failure and retried in a loop.
• Cancellation wins. Cancelling during reconnect backoff now remains a cancellation rather than surfacing the earlier offline error.
• Bounded recovery probes. When the API stops waiting for remote recovery, the CLI detaches that subscriber so it cannot linger behind the scenes.
• Rolling-upgrade compatibility. Transport errors carry explicit origin metadata while remaining compatible with servers and CLIs that have not yet upgraded.

This patch stops active Hermes, OpenClaw, and other service framework turns from being mistaken for stalled work when they run beyond the old fixed deadline.

Highlights

• Activity-aware timeouts. Streaming output now refreshes the inactivity budget, so productive long-running turns continue instead of being cut off after four minutes.
• Separate safety ceilings. Connection, inactivity, and maximum-duration failures are tracked independently and report which budget expired.
• Consistent runner transport. The same timeout model applies when a turn runs through a self-owned computer, including compatibility with older runners that still understand the legacy timeout field.
• Immediate cancellation. Cancelling an OpenClaw turn now aborts the live gateway request instead of leaving its response stream running.

This patch makes long-running agent turns safer when a daemon or API instance reconnects, and improves runner support for agents with custom workspaces.

Highlights

• Authoritative reconnect state. The daemon now distinguishes a confirmed empty stream list from a failed enumeration, so a reconnect cannot incorrectly mark active turns as lost.
• Longer resume window. Completed execution buffers remain available for 60 minutes, giving the platform time to finish draining or resume a turn across rolling deploys and transient disconnects.
• Custom workspace support. Runner daemons recognise the workspace roots of gateway frameworks, preventing outside allowed roots failures for co-resident coding agents.

This patch keeps the published CLI help readable and makes the distribution’s open-source license explicit.

Highlights

• Readable A2A agent guidance. mf help a2a --agent no longer ends with an empty code block or stray fence that could swallow the end of the guide in Markdown readers.
• Aligned command examples. The A2A command reference is aligned after the exposure and caller-management commands added in recent releases.
• Apache-2.0 licensing. The CLI package metadata and repository now carry the same Apache-2.0 license for source and standalone binaries.

The public CLI documentation now covers every command the binary registers, and a check keeps it that way.

Highlights

• Full command reference. A searchable reference generated from the same Commander tree as the mf binary, covering all 141 command paths in English and Chinese.
• New bilingual guides. Agents, runtimes, automations, backups, skills, usage, and outbound A2A each have their own page.
• Corrected help text. Profile-state and destructive-confirmation help matched neither the flags nor the paths the CLI actually uses; install, profile, daemon, scripting, and built-in agent guidance are accurate for 0.22 again.
• Complete release history. Every missing public CLI changelog entry through 0.22.0 is backfilled.
• Guarded against drift. Command syntax, required options, destructive confirmations, identifier prefixes, profile paths, bilingual coverage, reference drift, and release-history drift are now checked in CI, so the docs cannot silently fall behind the binary.

CLI credentials and daemon control state now live in named profiles, with commands to inspect and safely remove them. This is a breaking local-state migration.

Highlights

• Profile management. mf profile show, list, and delete expose the active environment, paths, login, and daemon state.
• Explicit selection. Use --profile <name> or MF_PROFILE; stable binaries default to default, dev binaries to staging.
• Per-profile daemon units. Production, staging, and self-hosted daemons can coexist with distinct state and autostart units.
• Shared agent data. Workspaces and the host skill store remain machine-scoped; deleting a profile never removes them.
• Headless setup repaired. mf login --no-launch-browser and mf setup --no-launch-browser now use the paste-back authorization-code flow correctly.
• Reliable re-registration. Duplicate machine/runtime display names no longer make setup fail, and API failures include an actionable trace ID.

Upgrade note

Legacy flat config and daemon fallbacks were removed. After upgrading from CLI 0.21 or earlier, run mf login and mf daemon register again in the intended profile. Existing data under ~/.manyfold/workspaces and ~/.manyfold/skills remains in place.

Hermes and OpenClaw turns can keep their upstream process and stream alive in the daemon while the Manyfold API restarts.

Highlights

• Daemon-owned turn transport. The daemon journals frames to its durable exec buffer while the API reads and replays them.
• Positive completion evidence. Recovery marks a turn complete only after the framework supplies its real end signal; ambiguous streams stay retryable.
• Faster runner presence. The daemon connects its WebSocket before slow framework probes, reducing false offline timeouts.
• Earlier Hermes validation. A missing primary model is rejected during creation instead of producing an unusable agent.

The CLI can manage hosted A2A exposure and callers, while runtime file transfers become stream-safe and capability-aware.

Highlights

• A2A lifecycle controls. mf a2a exposure and mf a2a callers manage public exposure, peer grants, External client tokens, and revocation.
• One-time External client bearers. Human output can be redirected straight to a secret store; endpoint guidance remains on stderr.
• Streaming upload/download. mf files upload and download keep memory flat and preserve an existing local file if a transfer fails.
• Agent context for files. Every file command can use --agent-id or MF_AGENT_ID, so the positional agent ID is optional.
• Visible transfer limits. mf files roots reports each transport’s real limits and capabilities; oversized uploads fail before transfer.
• Symlink containment. File operations reject symlinks that resolve outside the authorized root.

mf update can change the installed binary’s release channel and remember the choice for future checks and updates.

Highlights

• Explicit channels. Use mf update --channel dev for pre-release builds or --channel stable for production builds.
• Remembered selection. The machine stores its choice in ~/.manyfold/update-channel.json.
• Safe preview. mf update --check reports the selected channel without changing the saved preference.
• Consistent naming. Installer and daemon status use dev and stable; staging remains an accepted legacy alias.

Installing or re-enabling a skill no longer reports success before the skill has materialized in the agent workspace.

Highlights

• Explicit state. Installed skills report installing, installed, or failed independently from enabled/disabled state.
• Actionable failures. mf skills installed and mf skills install show a sanitized materialization reason.
• Background completion. Slow installs can continue after the initial request returns.
• Independent batch results. One failed agent does not abort other skill installs.

The one-line installer can pass control to interactive mf setup without logging forwarded secrets.

Highlights

• Install and onboard in one command. curl … | sh -s -- setup remains interactive.
• No unnecessary download. An already-installed matching version is reused before the requested setup command runs.
• Correct environment examples. Installer configuration examples now put variables on the process that actually consumes them.

The CLI gains guided machine onboarding, classified failures, stable exit codes, grouped help, and safer daemon lifecycle behavior.

Highlights

• mf setup. Sign in, issue a machine token, register the host, install autostart, and wait for daemon health in one command.
• Stable script failures. Network, auth, not-found, invalid-request, and other failures have distinct exit codes and structured JSON errors.
• Safer token input. --token - reads from stdin so secrets do not need to appear in argv.
• Idle daemon auto-update. Official init-managed daemons check every six hours and install only while idle; busy sessions are never interrupted.
• Offline daemon status. A local protected control socket reports daemon version, connectivity, and active sessions without contacting the cloud.
• Bounded logs and strict state. Logs rotate, secret-bearing state writes are atomic, and corrupt configuration fails with an actionable message.

Agents can proactively send channel messages and files, while users can build, import, share, export, and distribute their own skills from the CLI.

Highlights

• Agent-initiated channel sends. mf channels send can target a chat, DM, or native reply and can attach workspace files on supported providers.
• Personal skill library. mf skills library adds create, edit, import, export, delete, and supporting-file management.
• Unlisted skill sharing. Create or revoke a share link and import a snapshot from another user’s link.
• Batch distribution. Install a skill on several agents and push edited library content to existing installs with per-agent results.
• Current model catalogs. Claude Code, Codex, and Gemini CLI support the newly available model families and corrected usage/pricing metadata.

Long-running chat and delegated (A2A) agent turns are now resilient to brief network interruptions between your session and the agent’s sandbox.

Highlights

• No more mid-turn drops. A transient connection blip no longer kills an in-progress agent turn — work that was running keeps running and reconnects instead of dying 10 seconds later.
• Cancel still stays prompt. When you intentionally cancel a turn or it hits its timeout, it now stops immediately rather than lingering.
• Clearer async guidance. mf agent help now documents that --async delegated turns are not unbounded — they still have a cap, just a longer one than blocking turns.

This release introduces a self-hosted sign-in experience, account-level connections your agents can use, and file attachments across chat — plus per-agent MCP tool configuration.

Highlights

• A new way to sign in. Manyfold now runs sign-in itself: email and password (with email verification), Google, and single sign-on (OIDC), all configurable by your workspace admins. Sessions are issued and revoked by Manyfold directly.
• Account connections. Link your GitHub, Cloudflare, and Composio accounts once, and Manyfold makes them available inside your agents — GitHub and Cloudflare as credentials, Composio as a set of ready-to-use tools.
• File attachments in chat. Attach files in the chat composer, send file and image parts through the OpenAI-compatible API, and upload files to Dify chat agents.
• Per-agent MCP tools. Choose which MCP tools an agent can use, per scope, right from the agent detail page.

Notes

• You may need to sign in again. As part of moving to the new sign-in, existing sessions were reset. On the sign-in page, use Forgot password to set an email password, or sign in with Google/SSO once your admin has enabled it. If you run into trouble, reach out to your workspace admin.

Every mf data and mutation command now supports --json, so you can script Manyfold end to end and parse both success and failure reliably.

Highlights

• --json everywhere. All data and mutation commands accept --json for machine-readable output; deletes emit { "ok": true, "id": ... }.
• Parseable errors. In --json mode, failures print { "error": { "message": ... } } on stderr with a non-zero exit, so scripts can branch on both outcomes.
• Secrets stay redacted. Channel output remains secret-redacted in JSON mode, and login --json reports the result without ever printing your token.

Notes

• Raw-stream and interactive commands (files read, daemon logs, daemon start/register/stop, update) keep their existing behavior.

The runtime host and sandbox detail pages gain an mf CLI version picker, so you can update a host to a specific build instead of only jumping to the latest. Stable and staging builds are surfaced where available, and daemons can pull a cross-channel build in non-production environments.

Highlights

• Install a specific mf CLI version. The runtime host and sandbox detail pages now include a version picker — update a host or sandbox to a chosen mf CLI version, not just the latest.
• Stable and staging builds, min-version filtered. In local and staging environments, both stable and staging builds are listed, filtered to the admin-configured minimum CLI version.
• Cross-channel daemon updates. In local and staging, a daemon can install a build from another channel (for example, a staging build on a stable daemon) when it runs a CLI that supports the daemon.update channel override. Production daemons stay on their own channel.

Notes

• The version picker lives on the runtime host and sandbox detail pages in the web app.
• Update with mf update --force --yes; existing daemons keep working.

The low-value agent diagnostics surface is retired across the platform. The CLI drops the mf agent diagnose and mf agent health-check commands; agent storage reporting stays exactly as it was.

Highlights

• Removed mf agent diagnose. The agent diagnostics probe — and the API endpoint behind it — is gone.
• Removed mf agent health-check. The agent health-check command — and the API endpoint behind it — is gone.
• mf agent storage-usage is unchanged. Storage reporting (and the web Storage tab) works exactly as before.

Notes

• These commands backed the Health, Diagnostics, and Extras tabs in the web agent settings, which are removed in the same release.
• Update with mf update --force --yes; existing daemons keep working.

mf whoami now recognizes hosted runtime identity tokens, so an agent can inspect its own authenticated identity and context without a human login.

Highlights

• Runtime identity support. Hosted agents no longer fail identity inspection.
• No token exposure. The command reports identity metadata, not the injected bearer.

Runtime agents can ask their owner for a narrowly scoped permission without replacing their existing grants or seeing a token.

Highlights

• Incremental permission grants. Approval appends the requested scope and keeps existing permissions.
• Owner-controlled consent. The agent prints a consent URL for its owner; the underlying token is never shown.
• Minimum scope by default. Agents can request only the capability the blocked operation needs.

The current command for this workflow is mf auth ensure --scopes <scope-list>.

The command-line tool is renamed from nca to mf, with an agent-facing help guide built in, more resilient logins, and safer channel output. Existing installs keep working — the legacy nca binary still self-updates onto the renamed CLI, and your config is read from the old location as a fallback.

Highlights

• Renamed to mf. The binary, commands, and docs now use mf (was nca). Config moves to ~/.manyfold (with read-only fallback to ~/.config/nca), and the local daemon migrates to ~/.manyfold/daemon on first run. Your API tokens and existing agents are unaffected.
• mf help --agent. A built-in agent operations guide that works offline and without login. mf help <topic> --agent covers 13 focused topics — auth, safety, channels, automations, files, model-config, skills, runtime, agent, backups, usage — with exact scopes and copy-pasteable commands; --json returns a stable envelope.
• Resilient poll-mode login. mf login --poll now persists the pending request, so an approval is no longer lost if the polling process exits before you approve (the common case in chat). The next mf command redeems the approved session automatically, and mf login --resume checks or completes it. Consent links now stay valid for 15 minutes.
• Channel secrets masked everywhere. mf channels get/create/update/list redact secrets at every nesting level, including Lark webhook verificationToken / encryptKey. Note: mf channels list --json now returns [redacted] for secret fields — read secrets from your own records, not CLI output.

Notes

• A new staging release channel lets you install pre-release builds: install.sh gains an MF_CHANNEL switch (staging builds point at the staging API and self-update independently of stable). Production install/update behavior is unchanged.
• Update with mf update --force --yes (or nca update from an older install); existing daemons keep working.

Claude Code and Codex turns running through a self-owned computer no longer exit immediately when the prompt is delivered through daemon exec.

Highlights

• Prompt delivery works again. Daemon exec now accepts and forwards stdin correctly.
• Backward-compatible recovery. The API-side fix restores existing daemon agents immediately; upgrading the CLI adopts the complete protocol fix.
• No workspace migration. Existing local agents and their files are unchanged.

Chat runs backed by your local nca daemon now survive transient daemon↔cloud connection loss — laptop sleep, network blips, or a server restart no longer kill an in-progress assistant turn with a claude_exec_failed error.

Highlights

• The daemon buffers exec output to disk and replays it after reconnecting, so a brief disconnect no longer loses work.
• When the daemon comes back, the cloud transparently resumes the in-flight assistant turn instead of failing the message.
• Messages whose daemon is temporarily offline are now held in a suspended state and resume automatically, rather than ending in an error.

Notes

• To get the new behaviour, update the daemon: nca update --force --yes, then restart any long-running daemons.
• Fully backward compatible — older nca versions keep working against the updated cloud API; the disconnect-survival path engages once you are on 0.11.0.

The product has been renamed from Cloud Agents to Manyfold, with new primary domains across the web app, API, admin, docs, and CDN. Existing CLIs, daemons, scripts, and bookmarks keep working during a grace period — old hostnames continue to respond, and the nca binary name is unchanged.

Highlights

• Product name in CLI help text, prompts, and output is now Manyfold everywhere it used to say “Cloud Agents” or “Netmind Cloud Agents”.
• New primary domains:
  • Web app: manyfold.ai (was agents.netmind.xyz)
  • API: api.manyfold.ai (was nca-api.netmind.xyz)
  • Admin: admin.manyfold.ai (was nca-admin.netmind.xyz)
  • Docs: docs.manyfold.ai (was docs.netmind.xyz)
  • CDN: cdn1.manyfold.ai (was cdn1.netmind.xyz)
• All old domains continue to serve during the grace period — web/docs apex 301-redirect to the new domain, API/admin/CDN respond on both hostnames — so existing CLI installs and integrations don’t need to change immediately.

Notes

• The CLI binary name remains nca for backwards compatibility. Existing shell aliases, scripts, daemon init units, and CI configs keep working unchanged.
• Sign-in: Clerk’s primary domain switched to manyfold.ai, so you may be asked to sign in again the first time you visit the new web app.
• To pick up the new binary, run nca update --force --yes. Existing daemons continue to run against the old API hostname until restarted.
• The GitHub repository moved from protagolabs/netmind-cloud-agents to protagolabs/manyfold. Old URLs are forwarded automatically by GitHub.

nca channels gains a sessions subcommand group for inspecting and managing the per-scope chat sessions that channel bridges create. Same primitives the in-channel slash commands and the web sidebar use, now scriptable from the terminal.

Highlights

• nca channels sessions scopes <channelId> — list scopes in a channel with their active session, total session count, and last activity timestamp.
• nca channels sessions list <channelId> [--scope-key <key>] [--include-archived] — list sessions, with active marker, channel session id, scope, and display name (🏷️ when user-set).
• nca channels sessions new <channelId> --scope-key <key> [--name <name>] — create a new active session in a scope; the previous active becomes inactive.
• nca channels sessions switch <channelId> <sessionId> — make a session active in its scope.
• nca channels sessions rename <channelId> <sessionId> <name> — set the channel display name (the 🏷️ label that shows in /list inside the channel and in the web sidebar).
• nca channels sessions delete <channelId> <sessionId> [--activate-fallback] — archive a session; with --activate-fallback, auto-activate the newest remaining if you delete the active one.

Every command supports --json to emit raw JSON for piping into other tools.

Notes

• Slash commands inside each connected channel — /new, /list, /switch, /current, /rename, /delete, /help — are now always on and mirror the CLI semantics.
• Display name and chat-session title are independent: rename in the CLI / web “Rename channel display” updates display_name; rename in web “Rename session title” updates the chat-session title. Either appears in the web sidebar; the 🏷️ marker indicates a user-set channel display name.
• nca update --force --yes pulls the new binary; existing daemons keep working unchanged.

nca daemon start now installs an OS init unit so the daemon auto-starts at login and is automatically restarted by the operating system if it crashes. The web app’s Settings → Local daemons also shows each connected machine’s CLI version and how its daemon was launched.

Highlights

• nca daemon start installs a per-user init unit by default — macOS launchd LaunchAgent (~/Library/LaunchAgents) or Linux systemd user unit (~/.config/systemd/user). The daemon now auto-starts on login and is restarted on crash by the OS.
• nca daemon start --system installs a boot-time unit (requires sudo): /Library/LaunchDaemons on macOS or /etc/systemd/system on Linux. Use this on always-on machines that should run the daemon before any user logs in.
• nca daemon start --foreground runs the daemon inline without touching any init unit, useful for debugging and CI. nca daemon stop cleanly removes the init unit it installed, and nca daemon status / nca daemon doctor now report both user- and system-scope unit state.
• Each row in Settings → Local daemons → Connected machines now shows the daemon’s CLI version and how it was started, e.g. cli 0.8.0 · autostart · login (launchd) or cli 0.8.0 · manual.

Notes

• Existing daemons keep running unchanged; the new init unit is only installed the next time you run nca daemon start. Run nca daemon stop && nca daemon start to opt in.
• Use nca update --force --yes to reinstall the latest standalone binary, then nca daemon doctor to confirm the init unit was installed correctly.

nca daemon register now offers to start the daemon immediately after registration, so connecting a new local machine takes one extra keystroke instead of a second manual command.

Highlights

• After nca daemon register --token <TOKEN> succeeds in an interactive shell, the CLI prompts Start the daemon now? [Y/n]. Pressing Enter or y starts the daemon detached; pressing n keeps the existing register-only behaviour.
• Added -y / --yes flag for non-interactive setups (CI, unattended provisioning): nca daemon register --token <TOKEN> -y registers and starts the daemon in one shot, no prompt.
• Behaviour in non-TTY shells without -y is unchanged: the command only registers and prints the existing Next: run nca daemon start hint.

Notes

• The web app’s Settings → Local daemons now renders the full nca daemon register --token <TOKEN> command in a copy-ready block so it can be pasted straight into a terminal — see the new Register a local machine doc for the end-to-end flow.
• Use nca update --force --yes to reinstall the latest standalone binary.

This minor release significantly expands the CLI surface, adding new top-level command groups for managing Cloud Agents resources, plus per-agent token binding support for the OAuth grant flow.

Highlights

• Added new top-level command groups: nca model-config, nca files, nca automations, nca backups, nca skills, nca usage.
• Expanded nca agent (alias agents) with get, update, delete, diagnose, health-check, storage-usage, model-config, and credentials.
• Expanded nca runtime (alias agent-runtimes) with control-ui, dashboard, and agents {add,list,remove}.
• nca login --poll accepts --limit-to-agent to bind the new token to a specific agent (full API support lands in a follow-up).

Notes

• Runtime helper markdown emitted by agents now lists every CLI subtree; the legacy raw-curl Path-B section is removed.
• Use nca update --force --yes to reinstall the latest standalone binary.

This minor release adds CLI support for managing Cloud Agents channels.

Highlights

• Added the nca channels command group.
• Added commands to list, create, inspect, update, delete, test, and register channels.
• Added global agent context support with --agent-id and NCA_AGENT_ID for channel workflows.

Notes

• Use nca update --force --yes to reinstall the latest standalone binary after the release workflow publishes it.

This minor release updates the CLI and local daemon protocol for the current Cloud Agents runtime contracts.

Highlights

• Added external runner daemon protocol support.
• Updated the standalone CLI binary against the latest shared SDK contracts.
• Kept local daemon integrations aligned with current API, chat, and runtime metadata shapes.

Notes

• Users running local daemon-backed agents should update their CLI binary before using external runner workflows.

This patch release keeps local daemon runtimes compatible with per-agent model configuration.

Highlights

• Added daemon protocol support required by per-agent model configuration.
• Added model-aware chat session support across API, SDK, web, and local daemon integrations.
• Repaired managed credential handling used by managed model providers.

Notes

• Users should update local CLI binaries when using agent-specific model settings with local daemon runtimes.

This minor release updates the CLI and daemon runtime protocol for newer Cloud Agents workspace behavior.

Highlights

• Added support for custom workspace directories across hosted and local agent runtimes.
• Repaired local terminal session handling for daemon-backed agents.
• Improved runtime diagnostics by using the runtime kind when checking agents.
• Added support for Unicode agent display names.
• Updated object-id-compatible runtime naming used by hosted sprite-backed agents.

Notes

• This release includes protocol and runtime compatibility updates for the broader Cloud Agents product, not only command-line UX changes.

This patch release hardens local daemon process management and CLI authentication session handling.

Highlights

• Hardened nca daemon start and stop behavior with shared pidfile handling.
• Added stale-pid recovery when a previous daemon process exited unexpectedly.
• Added a start lock to avoid overlapping daemon launches.
• Propagated daemon-stopped state back to agents more reliably.
• Bounded CLI login sessions and consumed login state atomically.

Notes

• This release focuses on reliability for local machine runtimes and browser-based CLI login.

This release improves the first-run CLI experience and makes the standalone binary point at the production Cloud Agents API by default.

Highlights

• Added browser-based nca login with a loopback callback for local machines.
• Added a headless auth-code login path for environments where opening a browser is not practical.
• Switched the default API URL to the production Cloud Agents endpoint.
• Renamed daemon login flows around machine registration language.
• Added the nca update self-update command.
• Fixed daemon spawn arguments in Bun-compiled binaries.

Notes

• This version is the first CLI release backed by Changesets-generated package release notes.

First public build of the nca CLI, distributed as a standalone binary.

Highlights

• One-line install on macOS and Linux: curl -fsSL https://cdn1.netmind.xyz/cli/install.sh | sh
• Five platform binaries: linux-x64, linux-arm64, darwin-x64, darwin-arm64, windows-x64
• Browser-based login from the terminal
• Commands for listing agents and runtimes
• Local machine registration through nca daemon
• Built-in CLI update checks
• SHA256 sidecars for every asset

Notes

• The first CLI release focuses on sign-in, listing, runtime inspection, updates, and local machine registration. Rich chat and terminal workflows are available in the web workspace.