Changelog

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 NarraNexus 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 NarraNexus workspace roots, 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.