Release Notes

Scion release notes are published for each preview and stable release. Earlier notes were published weekly.

Releases

Global catalog writes need the global permissions and the `core` skill scope is retired

Writes on global (hub catalog) skills and templates are now decided only by new global permissions: skill.create_global (existing), skill.update_global and skill.delete_global for skills, and template.create_global, template.update_global and template.delete_global for templates, with matching token scopes (skill:update_global and so on, with a colon) on hub tokens only. The plain skill.update, skill.delete and template.* permissions no longer authorize any write on a global record, and owning a global record grants nothing. The global-catalog-author role (revision 3) now holds exactly these six permissions, so a non-admin user bound to it can create, publish, update and delete global skills and templates, including from CI with a hub token, without any authority over project- or user-scoped records. There is no transition period.

Re-mint tokens that write the global catalog. Existing user access tokens whose scopes are plain skill:update, skill:delete or template:*, including hub admins’ tokens, no longer write global records (403). Mint a new hub token with the *_global scopes; see Hub-boundary tokens for global catalog authoring for the CI recipe. These scopes are not part of skill:manage or template:manage.
Owners of global skills lose edit and delete unless they hold the role. The user who created a global skill can no longer update, publish to, deprecate or delete it, or see its draft versions, without global-catalog-author or hub-admin. Global templates record their creator for audit only; the creator gets no rights from it.
hub-admin (revision 12) gains skill.update_global and skill.delete_global (revision 11) and template.create_global, template.update_global and template.delete_global (revision 12). It does not gain the plain template.* permissions, so it still cannot write templates in projects it is not a member of. super-admin is at revision 12.
Custom roles that hold plain template.*, skill.update or skill.delete keep their reach over project and user records but lose writes on global records. Add the matching *_global permissions to such roles if their holders should keep writing the global catalog.
Import and refresh overwrite with template.create_global. Importing into the global catalog, or refreshing a global template from its source, needs only template.create_global, also when the template already exists, so that permission can replace an existing global template’s files.
Global skills on the hub-wide injected list. Every holder of skill.update_global can change the content of a global skill on the Hub’s injected list, which reaches every agent. Review that list; see Global catalog authoring.
scion skills publish --scope <scope> now adds the version only to a same-named skill in that scope (the current project’s for project, the caller’s own for user), so a global publish never lands on a same-named project or user skill; without --scope the lookup is by name only, as before. scion skills publish --scope global, scion templates update --scope global (or --global), and scion --global templates delete and scion --global templates clone link and look up no project, so they work with a hub token holding no project:read, and templates update also with --hub <url> outside a project. On the web settings page’s global Templates tab, Import, Clone and Refresh All from Source appear only for users who can create global templates, and Delete per template by capability.

The core skill scope is retired. Skills now have three scopes: user, project and global.

On upgrade, the Hub turns every core skill into a global skill. If a global skill with the same slug already exists, the former core skill is renamed <slug>-core (then <slug>-core-2, and so on) and the Hub logs a warning with the old and new names. The skills’ files are not moved.
Stored injection references to core skills (the Hub’s injected list and project and user injected skills) are rewritten to skill://scion/global/<slug>, using the new slug for a renamed skill.
A skill URI with a core scope (skill://core/<name>, skill://scion/core/<name>) is rejected with an error naming the global replacement, and scope=core on GET and POST /api/v1/skills answers 400, for delegated credentials too. The CLI’s --scope core is refused.
Template files that hard-code skill://core/... are not rewritten and now fail skill resolution with that error. An existing agent whose stored configuration holds a core skill URI keeps running; when its Runtime Broker provisions it again (for example, a start that re-provisions the agent), a required core reference fails provisioning with that error, and an optional one is skipped with a warning. Update such references to skill://scion/global/<name>, the recommended form.
A core reference that pointed at no skill before the upgrade may now resolve to a global skill of the same name.
skill://global/... and skill://core/... now always mean the local Hub’s global scope (or are rejected), even where a federated skill registry named global or core is configured. Older binaries still read a skill://global/<name> reference as a federated registry named global, so a reference written after the upgrade in that form (rather than one the migration rewrote) no longer resolves locally if the Hub is downgraded. Write skill://scion/global/<name>.

There is no schema change and no downgrade floor bump. See Global catalog authoring and Skills: scopes and resolution order.

Switch an existing agent’s harness-config

With the server-layer hub.reincarnate_harness_switch experiment enabled (alpha, off by default), scion reincarnate <agent> --harness <harness-config> selects a harness-config while keeping the agent’s identity, workspace, branch and Hub history. It deletes and rebuilds the agent home, including when the name is unchanged: the old harness session, transcripts, memory edits, installed tools and dotfile edits are lost. There is no rollback. Run --dry-run first to review the HOME RESET warning and provide a handoff for continuity. Supported runtimes are Docker, Podman, Apple Container, Cloud Run / Cloud Run Instances and Kubernetes; agents in worktree-per-agent projects remain unsupported. See Switching harness-config for requirements and recovery.

Agents receive their owner’s own material only along a recorded delegation chain

Agents created from a user access token, and their descendants, now receive their owner’s material only along a recorded delegation chain. At the agent’s next create, start, resume or restart, the owner’s user secrets and env vars that are not marked for progeny, the owner’s user TZ and the NoAuth clone token are withheld from any agent whose chain is not recorded to its owner. The owner’s user secrets marked for progeny are withheld from any agent whose chain is not recorded, and runtime reads and listings of them are refused (chain_unrecorded) for the same agents; a refused read answers as a missing key. An agent with no stored ancestry is no exception: it keeps the owner’s shared secrets only when its chain is recorded to the owner. The required-key check before a start and the environment gather treat such a withheld secret as missing, so the gather prompts for it. An agent whose delegation is not recorded cannot clone at start until its owner reclaims it (or re-creates it). This includes agents whose authority another user re-recorded (for example by reincarnating them with --role), sub-agents whose ancestry does not start at the owner, and agents whose chain was never recorded. A lower-scope value with the same key still applies. Launch material is no longer inherited by older descendants of token-created agents whose delegation predates this release. There is no transition period.

To restore an affected agent, its owner reincarnates it from a CLI session (scion reincarnate <agent>, keeping its role) or re-creates it. hack/delivery-census lists affected agents before and after the upgrade, including a runtime read section, with the names (never values) of the withheld rows, among them the owner’s shared secrets that start withholds; treat its output as operator-only. The Hub logs one warning per agent and site, and counts scion.hub.user_material.owner_chain with outcome=withheld. Project secrets are not affected. See Your Own User Values Follow the Agent’s Delegation Chain.

Weekly notes (through November 1, 2026)

Scion now requires TLS off loopback between the Hub and Runtime Brokers (server.trusted_proxies) with single-use nonced requests, runs host-side git without host credentials while checking repository git config before start, and refuses mounts that reach Runtime Broker control files or exceed an agent’s NFS scope while disabling Kubernetes API token automounting on agent pods. Authorization along recorded delegation chains now governs user-scope secrets, GCP service-account token minting and lifecycle hook tokens, agent and user JWTs and conduit relay tokens use the server keyring’s versioned signing ring, Hub-dispatched starts require a Hub-issued token, and user- and Hub-level secrets and environment variables require an interactive login. Shared server.project_storage reached Kubernetes and Cloud Run with centralized validation, Hub-side shared-tree deletion and Hub-signed workspace bootstrap URLs, while asynchronous agent launch (hub.async_agent_launch), chat attachment artifacts (hub.attachment_artifacts) and starred messages (web.chat_starred_messages) graduated to default-on. On the client and operator side, scion ships a native Windows client CLI (amd64 and arm64), single-node VM Hubs gained self-update under /opt/scion with Runtime Broker plugin updates, confirmed downgrades and boot-failure rollback, and the CLI added scion hub settings, project-defaults, experiments and delegation commands alongside per-schedule time zones, Unlimited count limits (0), and an opt-in pi harness.

Read the full release notes for this week ->

Hub-scoped secrets reach agents only as environment secrets

Hub-scoped secrets now reach agents only when their type is environment, apart from the telemetry credential file (see below). Hub-scoped file and variable secrets are no longer delivered to agents at create, start, restart or during credential gathering; a Runtime Broker-scoped secret with the same name now applies in place of those file and variable secrets. A Hub-scoped environment secret with the as_needed mode is not placed in the agent environment at start; it is supplied only when the agent’s harness requests that key during credential gathering. The telemetry credential file (scion-telemetry-gcp-credentials, type file, with a target path whose last two parts are .scion/telemetry-gcp-credentials.json) is still delivered. Hub-scoped environment variables, and secrets at User, Project and Runtime Broker scope, are unchanged. Before upgrading, move any Hub-scoped secret that agents need as a file or a variable to Project or User scope. See Hub-Scoped Secrets.

Kubernetes agent pods no longer mount a Kubernetes API token

Kubernetes agent pods no longer mount a Kubernetes API token. Restart running agents to apply this to them. To list agent pods that still have a token across all namespaces, see Agent pod identity.

Runtime Brokers that cannot receive commands are shown as such

A Runtime Broker is online while its heartbeats arrive, but heartbeats do not use the control channel that carries commands to it. A Runtime Broker whose control channel to the Hub was not connected, for example because the Hub’s transport check refused it, still looked healthy. Its health now reports control_channel as healthy (connected) or unhealthy (not connected for more than 90 seconds, or refused by the transport check), and nothing while it is starting or reconnecting within those 90 seconds; unhealthy marks the broker degraded. A Runtime Broker connected to several Hubs tells each Hub only about its own control channel. The Hub’s health summary adds the broker_command_path item “is online but cannot receive commands”, scion doctor counts such brokers, and scion runtime-broker status prints a Commands: line per hub connection and, while the broker is online, for the broker as the Hub sees it. Its former Connected: yes line, which only checked that the Hub API answered, is now Hub API: reachable. A hub connection is reported connecting until its control channel’s handshake completes, instead of connected at once. Online status and routing are unchanged.

Before upgrading, check server.trusted_proxies. A Hub whose TLS ends at a proxy on another host, or at a proxy container on a bridge network, must list the proxy’s addresses, or remote Runtime Brokers cannot connect. The Admin -> Maintenance update-binary and rebuild-server operations now print a ==> Settings check section that lists required settings left unset; it only warns. See the upgrade checklist.

Agents created from a user access token receive shared secrets and launch material again

An agent created from a user access token now receives your user-scoped secrets shared with progeny (--allow-progeny) at create, start, resume, restart and as_needed resolution, as an agent created from a sign-in does. Since the start-time user-secret check, such agents started without them, for example without harness credentials or personal tokens (miller79/scion#202). The agent-only permissions secret.deliver, env_var.deliver, skill_injection.deliver and secret.use are now intrinsic to the agent’s token-recorded edge: the token’s scopes do not narrow them, and no token scope is added for them (ptone/scion#6467; the decision that secret.use gets no selector is recorded on ptone/scion#2340). This applies to existing agents at their next start, with no migration. Every other check on each item still applies, and runtime secret reads and the full agent role still need project:secret:read, which no token grants.

Project, Hub and Broker launch material for these agents is now admitted by the regular delivery check instead of the uat_created_no_deliver_mapping exception, so its Warn line (exception=product_gap) no longer appears. Agents created from a user access token, and their sub-agents, now need their creating user to remain a member of the project to receive launch material, as session-created agents already do. The withheld Warn line names the cause, root user not admitted to the project. Uses of the intrinsic rule are counted in scion.hub.authz.uat_intrinsic. hack/delivery-census reports token-created agents (stored against filtered role, how many owner shared secrets the start-time check admits, and those withheld because their creator left the project). Thanks to Anthony Lofton for identifying and verifying the problem and for the test matrix this change ports (miller79/scion#199). See Agents created from a user access token.

Agent mounts that reach Runtime Broker host files are refused

A Runtime Broker now refuses any agent mount whose host source reaches its own credentials, local settings, identity and state files, plugins or co-located Hub database, read-only or not. This includes any source that contains the Scion global directory, such as ~ or /. Inside ~/.scion, volumes: and shared directories may only use workspace, worktree and shared-directory subtrees. Harness auth files and SCION_DEV_BINARIES may not come from ~/.scion at all, and relative bind sources are refused. A refused create or start returns 400 with the code control_path_mount, and a broker whose worktree base or NFS mount root reaches these files does not start.

The broker also records each container’s binds when it creates it and re-checks running agents. Running Docker and Podman agents created before this release are checked against the binds the runtime reports, and keep running if those are clear. They are stopped if any bind reaches these files, if a bind source does not exist on the host, or if the container runtime is not reached over a local unix socket or that cannot be determined, including a remote daemon selected through a Docker context or a Podman connection. A remote daemon reached through a local unix socket, such as an SSH-forwarded socket or a socat proxy, is treated as local; this affects only agents created before this release. Running Apple container agents created before this release are always stopped once. Stopped agents are marked error, and their workspaces are kept; start them again. See Volume Source Restrictions.

A Runtime Broker whose server.project_storage uses a shared backend reads project configuration and prepares project directories through its own view of the share, at <mount_root>/<shares[0].id> (nfs) or /mnt/<volume_name> (gke-shared-volume, cloudrun-volume). If that directory (with its <subpath_root>) is not there, the Runtime Broker refuses to create agents in shared-storage projects (503 project_storage_unavailable) and reports it in its health: /healthz shows project_storage: "unhealthy: share_not_visible (…)" and the status is degraded (readiness is unaffected), and the heartbeat to the Hub reports project_storage: unhealthy. The refusal refers to the share’s mount point as “its configured mount point”, never by its path, and says what to do for that Runtime Broker:

Runtime Brokers whose default runtime is Kubernetes or Cloud Run (including a Runtime Broker co-located in a Cloud Run or Kubernetes Hub) never mount the share themselves. Make it available in the Runtime Broker’s container at that path. A Cloud Run Hub’s NFS volume at <mount_root>/<shares[0].id>, or the Helm scion-hub chart with workspaceStorage.nfs.enabled: true, already does this. A separate Runtime Broker pod needs the volume added.
Other Runtime Brokers: mount it at that path, or set server.project_storage.nfs.auto_mount: true. If auto_mount is already on and the mount fails, the refusal says so and points at the NFS server and export and the Runtime Broker log.
Check: list <path>/<subpath_root> in the Runtime Broker’s container; it shows project IDs.

Changed status codes and texts. On a Kubernetes runtime, a create, start or restart that fails because the share is not mounted on the Runtime Broker now gets 503 project_storage_unavailable with that path-free text, instead of 500 runtime_error with the generic “Failed to create agent”. An async launch reports the same code and text, and the Hub passes the Runtime Broker’s 503 project_storage_unavailable through to the client with its code instead of a 502 runtime_error; the Hub passes the message on only when it is one of these path-free texts, and otherwise (for example from an older Runtime Broker, whose message named the mount path) answers with a fixed text. The same holds when a message, agent DM or chat message sent with wake resumes a suspended agent, which now answers 503 project_storage_unavailable instead of 502 runtime_error, and for the warning of a provision-only create and the error recorded for a reincarnation or move, which carry the code and the filtered text. The 503 nfs_unavailable refusal of an NFS-backed create no longer includes the share ID, the mount point or the server and export, with or without shared project storage; the Runtime Broker log has them.

Lifecycle hooks re-check their writer before minting a token

An http lifecycle hook with an execution identity now mints its service-account token only if the hook’s writer (createdBy) still qualifies at that moment. The writer must still be an active user created before the hook, must still hold hub.lifecycle_hooks.update, and, when the GCP IAM check is enforced, must still be able to act as the service account. The service account must still be verified and in scope. Before, these were checked only when the hook was written. When a check fails, the request is not sent, and the execution audit records hook writer no longer authorized with the failed check, at most once every 10 minutes per hook and cause. Existing hooks stop authenticating if their writer was deleted, suspended or demoted, if the writer’s email changed, or, with the IAM check enforced, if the writer lost actAs. Updating a hook does not change its writer. To restore such a hook, an admin who holds the authority today re-creates it. On a Hub that uses development authentication, every http hook fails if the development user’s stored email differs from the configured development identity’s email. Re-creating does not help there: make the configured email match the stored one, or update the stored email. webhook actions are unchanged. See Lifecycle Hooks.

Templates describe the job, not the environment

A template now describes the agent’s job (harness config, model, instructions, skills, tools, limits). Its environment (image, resources, volumes, Kubernetes settings, telemetry, hub access) comes only from the harness-config, settings and profiles, the hub and the project. See Settings Precedence and Agent Configuration.

Templates and environment keys (ptone/scion#4524, ptone/scion#4222):

A template’s telemetry, hub, image, resources, kubernetes and volumes are ignored with a warning, and the Hub no longer copies a template’s image, env or telemetry into agents. GET /api/v1/admin/validate-resources lists the affected templates (templateConfigFindings). Move these values to the harness-config or settings.
Template env: variables are now a lowest-precedence fallback: each applies only when no other source sets the key. Previously they beat settings harness-config env. Their values are no longer expanded from the broker host’s environment. SCION_* keys and every env key the harness-config’s auth metadata lists are never taken from a template (ptone/scion#4968). Template env is read from the template’s current version on every start, so edits take effect on the next start.
Existing agents: a template env key baked into an agent’s stored config with the same value as the template is treated as the fallback from the agent’s next start.

Precedence (ptone/scion#4222, ptone/scion#4223, ptone/scion#4218, ptone/scion#4217):

The Hub default model and thinking level apply only when neither the template nor the project sets one. The template beats the Hub default; the project still beats the template.
Requester telemetry is on/off only. Other inline telemetry fields are ignored with a warning, on every Runtime Broker.
Project telemetry policy beats --enable-telemetry / --disable-telemetry and SCION_TELEMETRY_ENABLED.
When a template sets both harness_config and default_harness_config, default_harness_config wins.
On the Hub, an explicit harness: key in a template wins over inferring the harness from the template’s name.

Template API and storage (ptone/scion#4223, ptone/scion#4222, ptone/scion#4221, ptone/scion#4217):

The template API rejects config (400 template_config_in_file) and image (400 template_image_not_supported) on create and update, and PUT updates metadata only. Edit scion-agent.yaml instead.
GET on a template returns a new read-only agentConfig, the parsed scion-agent.yaml.
Concurrent pushes of the same template: one wins, the other gets 409 template_conflict, and the CLI retries once.
Each template’s storage moves to a content-addressed layout, once, on its next commit. Unreferenced blobs are garbage-collected after a grace period (24 hours by default, never less than 1 hour).
Cloning a template whose bundled harness-config has an unusable provisioner fails with 422.
The template row’s stored config and image columns are removed. Their values have been ignored since the previous release and listed by the validate report; they are now discarded. The validate report’s stored_config kind is gone with them (ptone/scion#4224).

Settings are no longer baked into agents (ptone/scion#4241, ptone/scion#4561, ptone/scion#4222):

Broker settings telemetry and the settings- and profile-derived image, image pull policy, resources and volumes are applied at each start, not persisted in scion-agent.json. A settings or profile change takes effect on the agent’s next start. Hub agent_defaults.resources and the Hub default limits are also applied on every start (ptone/scion#623).
Agents created before this change keep their already-baked values until they are reprovisioned.
Agents created before ptone/scion#4222 keep a copy of the Hub default telemetry in their stored config until they are reprovisioned. Starting them no longer resends it.
Agents without recorded create inputs that are reincarnated keep any old template-derived env keys as explicit env, with a warning (ptone/scion#4224).

Minimum Runtime Broker version and upgrade order (ptone/scion#4224): the Hub no longer sends telemetry in the old inline form. Runtime Brokers older than the release that introduced the templateTiers capability (TS-2a, ptone/scion#4218) keep working but receive no Hub telemetry default and no project telemetry policy; the Hub logs a warning once per such Runtime Broker. Upgrade all Runtime Brokers to at least that release before upgrading the Hub to this one. This replaces the earlier advice to upgrade the Hub first. While the Hub is still older, an upgraded Runtime Broker receives Hub agent_defaults.resources only at create. It also gets no live template env: the older Hub sends no template identity on start, so the Runtime Broker uses the template version the agent was provisioned from if that version is still in its cache, and otherwise applies no template env, with a start warning.

`scion templates sync` and `push` accept a directory path

scion templates sync and scion templates push now also take a template directory path: . or .., an absolute path, or one that contains a path separator (such as ./name). The directory is synced as is, and the Hub name defaults to its base name (--name overrides it). Agents that share the project workspace see the project’s .scion directory read-only, so they now edit a template elsewhere in their checkout and sync it by path, for example scion templates sync ./templates/planner --name planner. An argument containing a /, and . or .., is now read relative to the current directory: before, sync a/b looked up <templates dir>/a/b, and sync . resolved to the templates directory itself. Bare names are looked up as before. See Templates & Roles.

The harness command line uses the Hub-resolved model

The --model argument a Runtime Broker passes to the harness now carries the same model as SCION_MODEL: the model the Hub resolved (request, then project default, then template, then Hub default), or an explicit SCION_MODEL from --env. Before, the argument came from the Runtime Broker’s own config, so a project or Hub default model could be shown on the agent while codex, gemini-cli or claude ran on the harness-config default. A size alias the Hub could not resolve is now resolved through the harness-config’s model_aliases, else the harness’s built-in alias table, instead of being replaced by the Runtime Broker’s own model. scion create also gains --model and --thinking-level, as on scion start (ptone/scion#3914, ptone/scion#378). See Settings Precedence.

The web Create Agent form no longer picks a harness config for you

The Create Agent form used to pre-select a harness config (the template’s, else the project or Hub default, else claude) and always send it, which made it an explicit request value: a project default_harness_config could never apply to an agent created from the web, and a template’s harness type was used as a harness-config name. The form now sends a harness config only when you pick one. Left unset, the Hub applies its own order (project default, then the template’s declared default_harness_config, then the Hub default), and the picker shows that inherited value as its placeholder (ptone/scion#3914).

`scion project list` lists projects across hubs

scion project list (and scion projects list) now lists the projects on all your registered hubs, each with its hub, merged with the project directories on this machine. Use --hub <hub> to show one hub and --refresh to fetch each logged-in hub’s project list. The earlier output, the project directories on this machine with their type, agent count, status and workspace, moved to scion project list --local, which keeps that format byte for byte, JSON included. Scripts that parse scion project list should switch to scion project list --local.

Posting in project chat threads needs `project.chat_post`

Reading a project’s chat threads still needs project.read. Posting in them, and promoting a direct message with one of the project’s agents into a thread, now also needs the new project.chat_post permission on the project. The built-in project-owner, project-admin and project-member roles and the hub-admin and super-admin system roles get it automatically on upgrade, so their holders keep posting. A send without it answers 403 chat_post_denied, and the web thread shows a read-only notice instead of the message box (ptone/scion#5518). See Chat posting. These chat writes do not check project.chat_post yet: thread create; thread rename, default-agent change and delete; project attachment upload; message edit and delete; and thread posts sent through the agent message endpoint (POST /api/v1/agents/{id}/message with a thread key). They keep their existing checks, and are tracked in ptone/scion#5519.

A new token scope, project:chat_post, keeps that permission on a user access token so the token can grant roles that include it. A token that grants project-member, or any other role that holds project.chat_post, through project:manage now also needs project:chat_post; mint a new token for existing membership automation. Posting by token is unchanged: inbox:write on the token and project.chat_post on your account.

Upgrade note: custom project roles are not changed. A principal whose only access to a project is a custom role that holds project.read but not project.chat_post can no longer post in that project’s threads, and their scheduled chat messages fail with no_access when they come due. This is intended: a role that only reads should not post. If such a role should keep posting, an administrator must add project.chat_post to it (Role & Binding Management).

Timezone handling changes

During the week of September 28 (release notes), timezone handling changed: the Hub sends every timestamp in UTC with Z, the web dashboard has a per-user display timezone and a 24-hour clock, and cron schedules are UTC only. The runtime-profile timezone setting introduced the week before (release notes) has been removed: an agent’s TZ now comes from its pin, TZ environment variables on the Hub, or the Hub default timezone. See Times and Timezones for the full behaviour and the operator steps after upgrading. An upgraded SQLite Hub now runs utc-timestamp-normalize once at start, after a database snapshot, so no manual step is needed; Admin → Maintenance shows the run as started by system:hub-start (ptone/scion#5194).

Deleted built-in harness configs and templates stay deleted

A deleted built-in harness config (for example claude) or the built-in default template no longer comes back when the Hub restarts or is upgraded (ptone/scion#3544). This also applies to harness configs left unselected in the setup wizard. The Hub records each built-in it has seeded in the builtin_resources_seeded Hub setting, and startup only creates built-ins that are not in that record. Built-ins that are new in a release are still added, and built-ins you keep still receive content updates.

To bring a deleted built-in harness config back, re-import it as a global harness config from its canonical URL, https://github.com/GoogleCloudPlatform/scion/harnesses/<name> (for example .../harnesses/claude). Use the import box on the Harness Configs tab of the Hub’s Settings page, or POST /api/v1/resources/import. On a hosted Hub, a copy imported from any other URL (such as a /tree/<ref>/ URL), or a re-imported default template, is usable but user-managed: it does not receive the content bundled with later releases. Workstation Hubs update it either way. See Recovering a deleted built-in.

Upgrade note: on the first start after upgrading, the Hub has no record yet, so built-ins you deleted since the last restart before the upgrade reappear once. Delete them again and they stay deleted.

Migration guides

Local-only mode removal: every agent command now goes through a Hub; after scion server start, each repository’s existing agents are imported on its first command.
Migrating from raw message delivery: raw keystroke delivery through messages is removed. scion message --raw fails before sending anything, and any message request that still carries raw is refused with 422 raw_input_removed. Use scion keys or POST .../keys instead.
Migrating from grove names: the grove→project rename.

Previous Weeks

Looking for older release notes? See the Prior Release Notes Archive for daily entries from the early development period (Feb–Jul 2026).