v0.3.0

Scion v0.3.0 is the stable roll-up of the v0.3.0 preview cycle (v0.3.0-preview.1 through v0.3.0-preview.7). Every agent operation runs through a Hub — either the local workstation server (scion server start) or a hosted Hub — with unified project management, content-addressed templates and skills, recorded delegation chains, and versioned cryptographic signing rings. For step-by-step history across the preview cycle, see v0.3.0-preview.7, v0.3.0-preview.6, and the weekly notes for October 26, October 19, October 12, October 5, September 28, September 21, and September 14.

Breaking changes and upgrade steps

• Upgrade order, database migrations, and downgrade floor (nightly-20261009):
  • Upgrade all Runtime Brokers to a release that advertises the templateTiers capability (and supports per-run Kubernetes Secrets) before or together with upgrading the Hub to v0.3.0. A v0.3.0 Hub omits inline telemetry fields from start payloads; older Runtime Brokers continue to run agents but receive no Hub telemetry default and no project telemetry policy (WARNING logged once per broker). During a multi-node rolling upgrade from a version without the Hub instance registry, keep hub.async_agent_start disabled until all Hub instances are upgraded; before a downgrade, disable hub.async_agent_start and wait the launch timeout plus 15 seconds.
  • v0.3.0 includes destructive schema migrations — dropping the stored config and image columns on template rows and executing DROP TABLE IF EXISTS decision_audits on startup (which takes an ACCESS EXCLUSIVE lock on PostgreSQL) — and sets DowngradeFloor to nightly-20261009. The Hub refuses self-update targets older than nightly-20261009 (below_downgrade_floor), and confirmed downgrades at or above the floor require explicit confirmation (409 downgrade_requires_confirmation). Take a database snapshot before upgrading; see Upgrading and Rolling Back a Hub.
  • On PostgreSQL, startup builds a (project_id, created, id) index on messages (blocking message writes until the migration commits) and a broker_dispatch (state, updated_at) index (on large deployments, pre-create it with CREATE INDEX CONCURRENTLY before upgrading). The Hub refuses to start if a later schema on the PostgreSQL search_path shadows Hub tables; fix search_path or set server.database.allow_shadowed_schema to log a warning and continue.
  • One-time post-upgrade and pre-upgrade maintenance steps:
    • Upgraded SQLite Hubs automatically take a database snapshot and run utc-timestamp-normalize once at startup (system:hub-start).
    • Run auto-expose-env-normalize once per existing Hub from Admin -> Maintenance.
    • GCP Secret Manager secrets use the scion-<hub hash>-... prefix; run scion hub secret migrate-names and update IAM conditions to the new prefix.
    • Correct or delete any user access token row with a non-UUID project_id before upgrading (boundary_kind is explicit and project_id is nullable).
    • Single-node VM Hubs without a repository path that relied on blanket sudo must run migrate-layout under /opt/scion before using self-update.
    • Agents using file-based harness authentication must re-authenticate once after upgrading.
    • Hook token metrics scion.hook.tokens.* are replaced by scion.usage.tokens{token_type} (recorded only when SCION_USAGE_SOURCE=hooks), and the /healthz summary drops stall_config; re-import the Hub telemetry dashboard and update alerts.
• Hub–Runtime Broker TLS, server.trusted_proxies, nonced signed requests, and Helm relay TLS:
  • Hub and Runtime Broker endpoints refuse non-loopback plaintext connections and mint Runtime Broker secrets and join tokens only over TLS or from the same host. Forwarded headers and the relay public listener trust only server.trusted_proxies (127.0.0.1 and ::1 with a startup warning when unset; an explicit list including [] is applied verbatim). A Hub whose TLS terminates at a proxy on another host or on a container bridge network must list that proxy’s addresses in server.trusted_proxies, or remote Runtime Brokers cannot connect and report control_channel: unhealthy (degraded). Run scion doctor or check the ==> Settings check output in Admin -> Maintenance update-binary / rebuild-server. See the Upgrade Checklist.
  • Every signed Hub↔Runtime Broker request requires a single-use nonce (401 "request already served" on replay within the clock-skew window) and caps signed request bodies at 2 MiB (413 payload_too_large).
  • In the Helm chart (deploy/helm/scion-hub), conduit.internalTls defaults to auto above one replica, requiring conduit.internalTls.existingSecret (kubernetes.io/tls) or conduit.internalTls.enabled: false, and any POD_NAME set through hub.extraEnv must be unique per pod. Deployments with a separate Conduit relay tier must follow the upgrade sequence in Separate Relay Tier.
• Local-only mode and assistant mode removed; Hub always required (scion server start):
  • Every command that manages agents, templates, or projects requires a configured Hub (No hub selected otherwise). Start the local workstation server explicitly with scion server start --foreground; CLI commands never auto-start it, and existing local-mode project agents are imported into the workstation Hub automatically on the first command after startup. See Local-Only Mode Removal.
  • --no-hub, scion hub enable, scion hub disable, scion hub shadow, scion hub unshadow, SCION_CLI_MODE=assistant (cli.mode: assistant), and hub.enabled are removed or ignored (scion use replaces shadow directories; scion delete --cleanup-only replaces scion --no-hub delete).
  • The CLI imports Hub keys from settings.yaml into context.yaml once and uses the Hub list in context.yaml as the sole CLI Hub configuration (scion login does not switch the active Hub).
  • In workstation mode, scion server start binds the Hub (:9810), Runtime Broker (:9800), and web server (:8080) to 127.0.0.1 by default (--host / --bind moves only the Hub and web listeners while the Runtime Broker stays on 127.0.0.1 unless server.broker.host is set; with the web server disabled, scion server start refuses a non-loopback Hub host). The Hub’s agent port proxy sets server.hub.port_proxy.response_header_timeout ("60s" by default, range "5s" to "10m") and server.hub.port_proxy.view_ttl ("2h" by default, range "15m" to "24h", with hub.port_view). With development authentication enabled, web sessions are created only through a single-use launch link (POST /auth/dev-launch -> GET /auth/dev-signin, opened by scion server start or scion server open [--print]), and mutating /api/v1/system/* routes require a Hub admin.
• grove terminology replaced by project and legacy workspace env vars retired:
  • CLI commands, flags, API endpoints, wire payloads, SSE events, --json outputs, hubclient, container labels (scion.project*), and pub/sub topics (scion.project.*) use project exclusively (/api/v1/groves returns 404; /api/v1/workspace/grove-upload is replaced by /api/v1/workspace/project-upload; "grove" is rejected as a scope with 400; resolved secrets report source: "project").
  • scion grove, scion hub groves, scion config cd-grove, --grove, the grove: template-scope prefix, top-level grove_id in settings.yaml (only hub.grove_id remains accepted as a compatibility alias for hub.project_id), the grove-id marker file, SCION_GROVE_ID, SCION_GROVE, SCION_GROVE_PATH, SCION_HUB_GROVE_ID, and SCION_SHARED_WORKSPACE are removed (SCION_WORKSPACE_MODE and SCION_WORKSPACE_GIT are the sole workspace mode variables; SCION_HUB_PROJECT_ID outranks the project-id file and hub.project_id; inside agent containers an explicit --project flag beats SCION_PROJECT_ID, and -g global resolves the Hub’s Global project).
  • Broker error code global_grove_disabled is renamed to global_project_disabled, and groves: in a2a-bridge and fs-watcher configs is replaced by projects:. When a project contains .scion/grove-id, it is ignored (rename it to .scion/project-id), and ~/.scion/groves/ and ~/.scion/grove-configs/ are moved to ~/.scion/projects/ and ~/.scion/project-configs/ (when both exist, scion warns and uses the project-named directory). Restart agents created before the rename. See Migrating from Grove Names.
• Raw message delivery (--raw), assistant-reply mirror, and chat notification rows retired:
  • scion message --raw and "raw": true on message ingress endpoints are removed (422 raw_input_removed). Send terminal keystrokes with scion keys <agent-name> <keystrokes> or POST /api/v1/agents/{id}/keys (gated on agent.attach). See Migrating from Raw Message Delivery.
  • sciontool does not mirror each turn’s final assistant text (assistant-reply returns 200 {status: dropped}), and Telegram Commentary, ShowAssistantReply, and the Google Chat relay are removed; agents reply explicitly with scion message.
  • Chat MENTION and DM_RECEIVED notification rows and the web Messages inbox tray are replaced by unread counts from GET /api/v1/chat/unread-count, and chat history and interagent list endpoints return totalCount: 0.
• Templates describe the job, not the environment, and resource names are single-component:
  • Environment keys in a template’s scion-agent.yaml (telemetry, hub, image, resources, kubernetes, and volumes) are ignored with a warning, and the Hub does not copy a template’s image, env, or telemetry into agent records. GET /api/v1/admin/validate-resources lists affected templates under templateConfigFindings. Move environment keys to harness-configs, settings, or runtime profiles.
  • Template env: entries act as a lowest-precedence fallback read from the template’s current version on every start without host environment expansion, and never supply SCION_*, GCE_METADATA_*, COPILOT_OTEL_*, GROK_TELEMETRY_*, GROK_EXTERNAL_OTEL, or any environment variable listed in the harness-config’s auth metadata.
  • The template API rejects config (400 template_config_in_file) and image (400 template_image_not_supported) on POST and PATCH, PUT updates metadata only, and concurrent template commits use compare-and-swap (409 template_conflict).
  • Settings- and profile-derived image, image_pull_policy, resources, volumes, telemetry, and Hub agent_defaults.resources / scalar limits are applied on every start rather than persisted in scion-agent.json. Runtime Brokers take an agent’s profile, harness-config, and runtime only from their image-provenance record and Hub start/restart requests; older agents with neither must be reprovisioned. See Settings Precedence and Agent Configuration.
  • Template names, harness-config names, and Runtime Broker IDs must be single path components (no /, .., leading :, or ://), and client-supplied project slugs must already be slugified. Template agent_instructions and system_prompt files must be regular files up to 4 MiB inside the template directory with symlinks not followed.
  • The visibility field is removed from agents, templates, harness configs, and skills; access is determined solely by scope and grants.
  • Deleted built-in harness configs and the default template are tracked in the builtin_resources_seeded Hub setting and are not re-created on restart or upgrade (on the first start after upgrading from v0.2.x, built-ins deleted since the previous restart reappear once; delete them one final time). See Recovering a Deleted Built-In.
  • gemini-cli agents without an explicit model resolve the medium alias on restart. For harnesses whose default auth type is api-key (claude, gemini-cli, grok-build, hermes), an API-key environment credential takes precedence over a gcloud-adc file credential, and Vertex AI location resolves in the order GOOGLE_CLOUD_LOCATION, GOOGLE_CLOUD_REGION, CLOUD_ML_REGION (required for Claude on Vertex AI).
• Unified server.project_storage, NFS readiness and nosuid,nodev, and retired WebDAV / GCS workspace sync:
  • server.project_storage replaces workspace_storage, shared_dir_storage, and home_storage (422 storage_invalid on invalid configuration; per-profile, per-runtime, and per-directory backend overrides such as shared_dir_storage_backend(s), home_storage_backend, and home_storage_leaf are rejected with 422 at agent start).
  • WebDAV (/dav/ returns 404), project-level scion sync (push, pull, and --force), the Hub project copy, GCS workspace upload/sync-back, and the linked-project cache are removed (agent-level scion sync to|from <agent-name> requires an explicit direction; on non-GCS Hub storage, creating an agent on a remote Runtime Broker with no local path in a project without a git remote fails with 412).
  • When server.project_storage uses nfs, gke-shared-volume, or cloudrun-volume, every Runtime Broker serving shared-storage projects must see the share at <mount_root>/<shares[0].id> (nfs) or /mnt/<volume_name> (gke-shared-volume, cloudrun-volume) with its <subpath_root>, or it marks project_storage: unhealthy (degraded) and refuses agent create, start, restart, or wake in shared-storage projects with HTTP 503 (project_storage_unavailable). Every Runtime Broker NFS mount requires nosuid,nodev (503 nfs_unavailable otherwise).
  • On nfs project storage, the Hub checks the share on /readyz (503 when unreachable) and is the sole remover of deleted project directory trees (200 with storageKept if unreachable on project delete, while Runtime Brokers retain their project directory while agents remain with 409). Without shares[0].pv_name, Kubernetes agent pods mount the NFS export inline directly (requiring a writable Runtime Broker mount at <mount_root>/<share id>, with NFS Agent homes refused). On shared NFS storage for Docker, Podman, and Apple container runtimes, clone-per-agent and empty-per-agent workspaces live on the share scoped to the starting agent.
• Git workspace modes, read-only .git / .scion mounts, host-side git credentials, and .git/config policy:
  • Unlabeled Git projects (or projects carrying a raw shared-plain label) default to clone-per-agent; only the shared label selects a shared checkout. Push shared-checkout work before upgrading.
  • Git projects on Kubernetes require clone-per-agent; worktree-per-agent and shared-workspace Git projects on NFS are refused at start on Kubernetes. Commit and push work from Kubernetes agents in shared/worktree Git projects before upgrading, or run those projects on a local or Docker Runtime Broker.
  • Repository clone URLs carrying a username, password, token, query, or fragment are refused; store clone credentials in project secrets or the GitHub App integration. Host-side git operations run through a guarded entry point with LC_ALL=C and never use host credential helpers, askpass, ~/.netrc, TLS client certificates, Kerberos, or host SSH keys: without a project git secret they run anonymously, with one only that secret is offered to the project’s recorded remote (https, ssh, or git), and SSH repository URLs require a project secret.
  • Before agent start on Docker, Podman, and Apple container runtimes, the Runtime Broker checks the repository .git/config and reachable worktree and submodule configs against an allow-list and refuses to start (git_config_refused) if execution-capable or redirect keys (core.hooksPath, core.fsmonitor, core.sshCommand, core.editor, core.pager, core.askPass, core.gitProxy, credential.*, filter.*, protocol.*, diff.*.textconv, diff.*.command, merge.*.driver, include.*, includeIf.*, or url.*) are present.
  • In worktree-per-agent and shared-workspace Git projects, .git/hooks, .git/info, .git/objects/info, sibling worktree admin directories, a sanitized read-only .git/config, and the project’s .scion directory are mounted read-only into agents (on Docker and Podman, a read-only project .scion must already contain an agents subdirectory: mkdir <path>/.scion/agents). Explicit project paths given to a Runtime Broker require an internal .scion directory or marker (409 project_path_not_initialized).
• Agent mount restrictions, container runtime audits, Kubernetes pods, and fail-closed starts:
  • Runtime Brokers refuse any agent volume or mount whose host source reaches the broker’s credentials, local settings, identity and state files, plugins, or co-located Hub database (400 control_path_mount), including /, ~, ~/.scion outside workspace/worktree/shared-directory subtrees, or relative bind sources. On upgrade, running Docker and Podman agents created before v0.3.0 are inspected against their runtime binds and stopped (marked error, workspace preserved) if any bind reaches broker control files, if a bind source is missing on the host, or if the container runtime is not reached over a local Unix socket; running Apple Virtualization (container) agents created before v0.3.0 are stopped once on upgrade. Start stopped agents again with scion start. See Volume Source Restrictions.
  • Kubernetes agent pods set automountServiceAccountToken: false in all GCP identity modes (block, passthrough, and assign), and set spec.serviceAccountName to kubernetes_block_service_account in block mode or the namespace default KSA otherwise. Restart existing agent pods after upgrading so they drop mounted Kubernetes API tokens; see Agent Pod Identity. Explicit GCP metadata block mode on Kubernetes returns 400, assign mode requires kubernetes_service_account_mappings (400 identity_not_mapped when unmapped), Kubernetes CPU/memory/storage requests are added only when no request or limit is set, and saving runtimes or profiles validates placement in a single guarded transaction (422 on new placement errors, 409 on conflict). Under Docker or Podman host networking, metadata block mode follows SCION_HOST_NETWORK_BLOCK_POLICY (auto refuses starts on detected cloud hosts; strict always refuses).
  • Hub-dispatched starts take the agent’s Hub token only from the token issued by the Hub (SCION_AUTH_TOKEN is stripped from the start environment, failing with agent.ErrNoHubToken if absent). Starts fail closed with 400 or 503 when an agent’s GCP service account is unverified or lacks gcp_service_account.use against its recorded parent authority (ceiling_provenance_missing; boot migration sa_assignment_legacy_backfill backfills legacy edges), when per-item secret delivery cannot read a selected secret, or when env-based harness authentication cannot be satisfied on the Runtime Broker before container creation. GitHub App installation tokens are minted only for the agent’s own project (or a verified cross-project token-source label).
• Authorization, RBAC permissions, Personal Access Tokens, schedules, lifecycle hooks, and deletion guards:
  • Authorization fails closed: only files in web/public/ skip the root-level web session check (other root paths redirect browsers to sign-in or return 401, including /robots.txt), OAuth/OIDC sign-in requires a provider-verified email, project access is granted only through role bindings (rather than Project.OwnerID), and agent.lifecycle is separated from agent.attach and agent.port_access on project-owner and project-admin roles (revision 3).
  • hub.federation.read/update, hub.teams_manifest.update, user.list, and agent.log_append are reserved and removed from built-in roles; Runtime Broker registration requires broker.create (granted through hub-member), Runtime Broker sharing/linking requires broker.update, Runtime Broker env/secrets/heartbeats check broker.* permissions, and max_agents_per_broker is enforced per broker (default 100 on new Hubs).
  • Posting in a project chat thread or promoting an agent DM into a thread requires project.chat_post (403 chat_post_denied). Built-in project-owner, project-admin, project-member, hub-admin, and super-admin roles receive project.chat_post automatically on upgrade, but custom project roles are not modified — add project.chat_post to any custom role that should remain able to post, and include the project:chat_post scope on user access tokens that grant roles containing it via project:manage. See Chat Posting.
  • User access tokens (scion_pat_...) require explicit inbox:*, quota:*, agent:*, user:promote, user:delete, and user_skill_injection:update scopes; cannot read, write, or delete user-scoped or Hub-scoped secrets or environment variables (403 CREDENTIAL_MANAGEMENT; interactive login via scion hub auth login or web session required); and cannot create or modify scheduled work.
  • Agents created from a user access token and their sub-agents require their creating user to remain a member of the project to receive project, Hub, Broker, and shared user (--allow-progeny) launch material (root user not admitted to the project when withheld). When a member is removed from a project, their agents are placed on hold and refused on start, messaging, token minting, secrets, schedules, and agent creation until a Hub admin calls POST /api/v1/agents/{id}/hold/lift (set server.hub.membership_sweep_report_only on first boot to audit without holding). See Agents Created from a User Access Token.
  • Existing dispatch_agent and message schedules created prior to delegation-authority recording must be paused and resumed or re-created so caller authority is recorded. Recurring cron schedules run in UTC by default or in the schedule’s explicit IANA timezone field (--time-zone); CRON_TZ= and TZ= prefixes in cron expressions are rejected with 400 (existing prefixed schedules are paused on upgrade — edit them to remove the prefix and resume). The temporary runtime-profile timezone setting is removed (422 on save); agent TZ resolves only from the agent’s pinned timezone (explicitTimezone), a Hub TZ environment variable, or the Hub default timezone (agent_defaults.default_timezone), while --tz <zone> and --utc set the CLI display timezone. See Times and Timezones.
  • Every http lifecycle hook with an execution identity re-checks at firing time that its creator (createdBy) is still an active user created before the hook, holds hub.lifecycle_hooks.update, and (when GCP IAM checks are enforced) holds actAs on the verified service account (hook writer no longer authorized otherwise; re-create affected hooks with a currently authorized admin, and on development-auth Hubs ensure the configured dev identity email matches the stored dev user email). See Lifecycle Hooks.
  • Deletion and lifecycle guards: deleting a project while agents remain returns 409 unless --force / ?force=true is passed; deleting a user who owns agents or active delegations returns 409 user_delete_blocked; deleting a referenced GCP service account returns 409 sa_in_use; removing the last active access-constraint admin returns 409 constraint_admin_lockout; pinned agents with stale placement return 409 (runtime_target_pin_stale, runtime_target_mismatch, runtime_broker_missing); agent delete can return 202 (409 delete_in_progress or 409 conflict on concurrent lifecycle actions); agent stats return 501 stats_not_implemented; scalar count limits (max_turns, max_model_calls) treat 0 as Unlimited (unset inherits); and project defaultThinkingLevel must be 1–100 or null (422 otherwise).
• Server configuration, environment variables, logging, and CLI flags/output changes:
  • Server startup settings load from the global directory only. --base-url outranks SCION_SERVER_HUB_ENDPOINT, SCION_SERVER_BASE_URL, and server.hub.public_url (refusing http on non-loopback listeners), server.hub.gcp_project_id is settings.yaml-only at startup (422 on DB-backed telemetry.cloud.cloud_logging saves), --test-mode=off|member|admin|super-admin requires a pinned server.hub.hub_id (hub_id_not_pinned) and is refused with --production, and SCION_SERVER_* / SCION_SEED_* variables use a single strict registry table that fails startup on unparseable boolean or numeric values.
  • Settings write APIs return 422 validation_error (details.errors), 409 revision_conflict on stale revisions, and 400 on unreadable bodies or edited masked placeholders; server.auth.authorized_domains applies live and refuses self-blocking saves with 422; malformed list cursors return 400 invalid_cursor.
  • SCION_LOG_LEVEL (supporting per-component levels such as info,hub.auth=debug) replaces server.log_format, SCION_TELEMETRY_DEBUG, and LOCAL_* variables (SCION_DEBUG is a deprecated alias). Agents do not inherit --debug (use scion start --agent-log-level), and /auth/debug requires --enable-debug-endpoints (refused in hosted mode).
  • CLI flags and output formats:
    • scion project list lists projects across all registered hubs merged with local project directories by default; scripts parsing the local-only table or JSON output must pass scion project list --local.
    • scion templates sync and scion templates push resolve any argument containing /, ., or .. relative to the current working directory (or as an absolute path) rather than under .scion/templates/; scion harness-config sync and push default to project scope (pass --global for ~/.scion/harness-configs). See Templates & Roles.
    • --project <slug> binds to the existing Hub project rather than creating <cwd>/<slug>; --gcp-project replaces --project on scion project service-accounts add, scion hub secret migrate, and scion hub secret migrate-names; scion list rejects positional arguments; scion logs --follow is removed; non-interactive scion start / resume requires --send-env to send local env values and never sends SCION_DEV_TOKEN* off loopback; and non-interactive confirmations default to No unless --yes is passed (prompts go to stderr).
    • Inside an agent container, scion delete and scion stop --rm require --self to remove the calling agent, scion expose and scion unexpose replace sciontool expose and sciontool unexpose, and scion secret get (--value) and scion secret list replace sciontool secret get and list.
    • scion doctor --format json uses formatVersion 2 (generatedAt, hub, platformHealth), scion config list / get JSON reports value sources with secrets masked, and group-send --format json returns {counts, results, retry_recipient} and exits 3 on partial delivery.
• Default agent image tag resolution (hub.image_tag_version_default) and stable container images:
  • On release builds (v0.3.0), the hub.image_tag_version_default experiment is enabled by default: when resolving a short-form scion-* agent image that has no tag or :latest, the Hub rewrites the tag to match its release version (:v0.3.0) unless image_tag: latest is configured (hub.image_tag_setting) or hub.image_tag_version_default is disabled.
  • Which prebuilt container images (core-base, scion-base, scion-hub, scion-hub-gke, scion-omni, and individual scion-<harness> images) are published for the v0.3.0 stable release, and the registry and tags (:v0.3.0, :stable, or others) under which they are published: To be confirmed at release.

Hub and Runtime Broker

• Asynchronous agent launch and start (hub.async_agent_launch, hub.async_agent_start):
  • When hub.async_agent_launch and hub.async_agent_start are enabled and the caller opts in with acceptAsyncLaunch ({"acceptAsyncLaunch": true}; requests that do not opt in run synchronously, and scion start / scion resume opt in and wait unless --no-wait is passed), agent creation (POST /api/v1/projects/{projectId}/agents) answers 201 and start or restart (POST /api/v1/agents/{id}/start, POST /api/v1/agents/{id}/restart) answers 200 with an active launch as soon as the Runtime Broker accepts the request, progressing through the active lifecycle phases (created, provisioning, cloning, starting, running, or error / stopped on failure). See Experiments.
• Shared project storage (server.project_storage) across local, VM, Kubernetes, and Cloud Run:
  • Hosted Hubs and Runtime Brokers support shared project storage backends (nfs, gke-shared-volume, cloudrun-volume) alongside local, validated centrally at startup (422 storage_invalid).
  • For Hub-managed workspaces on a GCS Hub, a Runtime Broker without Google Cloud credentials bootstraps the workspace from short-lived, GET-only, per-file Hub-signed URLs staged before placement (with workspace-bootstrap creates returning no upload URLs when a concurrent delete wins with 409 delete_in_progress).
  • Deleting a project on the Hub removes its shared storage directory tree on the Hub side and cleans up associated worktrees and volumes across attached Runtime Brokers.
• Content-addressed templates and skills (hub.content_hash_v2, hub.skill_content_hash_v2):
  • Templates are stored in a content-addressed blob layout on commit (GET returns the parsed scion-agent.yaml as read-only agentConfig), with unreferenced blobs garbage-collected after a configurable grace period (24 hours by default, minimum 1 hour). Concurrent template pushes return 409 template_conflict and the CLI retries once automatically.
  • First-class Hub skills (scion skills) store versioned skill packages with content hashes, attachment management on agents and templates, and symlink-free skill injection into agent workspaces at launch.
• Harness model resolution and size aliases:
  • The Hub resolves an agent’s model in strict precedence order (explicit request --model or SCION_MODEL, project default model, template model, Hub default model) and passes the resolved value to the Runtime Broker for both SCION_MODEL and the harness command-line --model flag. Size aliases (small, medium, large, default) resolve through the harness-config’s model_aliases map or the harness’s built-in alias table. See Settings Precedence.
• Runtime Broker control channel health and command-path diagnostics:
  • Runtime Brokers report control_channel health (healthy when connected, unhealthy after 90 seconds disconnected or when rejected by the Hub’s transport check) per Hub connection. The Hub’s /healthz summary includes the broker_command_path check ("is online but cannot receive commands"), and scion doctor and scion runtime-broker status surface control-channel reachability alongside Hub API: reachable.
• Single-node VM self-update, rollback, and Runtime Broker plugin updates:
  • Single-node VM installations deployed under /opt/scion support in-place binary updates (update-binary) and source rebuilds (rebuild-server) from Admin -> Maintenance, including atomic Runtime Broker plugin updates (~/.scion/plugins/broker), five database snapshots and settings backups, automatic boot-failure rollback via systemd, and confirmed downgrades (409 downgrade_requires_confirmation) down to DowngradeFloor (nightly-20261009).
  • Which stable container image tags are referenced by the Helm chart (deploy/helm/scion-hub) and single-node VM deployment script (deploy.sh with container_images.source: registry) for v0.3.0: To be confirmed at release.
• Separate Conduit / WebSocket relay tier (hub.conduit, hub.conduit_deliver):
  • High-availability deployments can run stateless WebSocket/SSE relay nodes separately from the Hub API tier, with keyring-signed relay admission tokens and optional message delivery over Conduit (hub.conduit_deliver); see Separate Relay Tier.
• Per-schedule IANA timezones, unlimited count limits (0), and quota slot release:
  • Recurring cron schedules accept an explicit IANA timezone (--time-zone), evaluated across DST transitions, and pause with creator_deleted if their creator is deleted.
  • Scalar agent count limits (max_turns and max_model_calls) treat 0 as Unlimited across the Hub API, CLI, and web UI, and stopped or suspended agents free their max_agents_per_project quota slot.
• Failed-message purging and chat retention (hub.chat_retention):
  • The Hub runs chunked failed-message purging (messaging.failed_message_retention_days, default 7) and experimental chat message and deleted-conversation retention sweeps (hub.chat_retention).

Web Dashboard

• Project chat threads, thread groups, starred messages, and attachment artifacts:
  • Project chat supports multi-participant threads with @agent and @all mentions, unread badges (GET /api/v1/chat/unread-count), and collapsible thread groups (hub.chat_thread_groups, graduated to always-on).
  • Users can star important chat messages (web.chat_starred_messages, enabled by default) and upload file attachments stored as versioned project artifacts (hub.attachment_artifacts, enabled by default whenever the artifact service is configured, including local blob storage).
• Create Agent and Edit Agent forms (web.agent_edit, hub.agent_edit_held):
  • The Create Agent dialog leaves the harness config unselected unless explicitly chosen, inheriting the resolved project, template (default_harness_config), or Hub default and displaying that inherited value as placeholder text.
  • The Edit Agent view (web.agent_edit, enabled by default) edits stopped agents’ configuration, model, thinking level, limits, pinned timezone, and attached skills in place, with optional saver-permission re-checks on held agents at start (hub.agent_edit_held).
• Terminal workspace (web.terminal_workspace):
  • The browser terminal workspace (web.terminal_workspace, graduated to always-on) provides multi-tab xterm.js sessions, clipboard integration, mobile/touch keybars, and tmux window controls on the agent detail page.
• Access boundaries, resource sharing, and artifact inspection and annotation UI (web.access_boundaries_read, web.access_boundaries_authoring, web.artifact_review_editor, web.artifact_manage_access):
  • Both access-boundary views are graduated to always-on: users can inspect effective roles, delegation policies, and shared resources across projects, and project owners/admins can author role bindings, groups, and access boundaries directly from the web dashboard.
  • Artifact views support versioned file browsing, graphical and line-level feedback comments (artifact_review_summary notifications to the artifact owner), .zip archive downloads (hub.artifact_archive), and a unified Manage Access dialog (web.artifact_manage_access).
• User profile timezone, 24-hour clock, and Personal Access Tokens UI:
  • User settings include a display timezone picker (with automatic browser detection) and a 24-hour clock toggle applied to every timestamp in the UI, plus creation and revocation of project- and Hub-boundary Personal Access Tokens (scion_pat_...) with scope selection, purpose, labels, and expiration dates. See Personal Access Tokens.
• Admin Server Config, Maintenance, Experiments, and Resource Validation panels:
  • System administrators can edit revision-guarded Server Config sections (including Kubernetes runtime placement/identity fields, maintenance banners, and agent start timing), toggle runtime experiments (/api/v1/admin/experiments), edit Hub settings and project defaults, inspect GET /api/v1/admin/validate-resources findings (templateConfigFindings), and run maintenance jobs (utc-timestamp-normalize, auto-expose-env-normalize, update-binary, rebuild-server, database backups) with live log streaming.

CLI

• Native Windows client CLI (windows/amd64 and windows/arm64):
  • scion builds and ships native Windows client binaries (amd64 and arm64) supporting the remote Hub client command set permitted by windowsAllowed: list, ssh, ssh-config, tunnel (tunnel status), vscode, message (message channels), messages (messages read), conversation, use (project use), project settings (get, set, unset), config, hub (auth, secret, settings, project-defaults, experiments, test-identity, token, profile, env, notifications, messaging, status, projects, brokers, enable, disable, link, unlink, hook, allow-list, shadow, add, list, rename, remove, users, invite), version, help, completion, and global-flags. Commands outside that set return an "is not supported on Windows" error.
• Hub and project administration commands (scion hub settings, project-defaults, experiments, project settings, hub delegation, server keys):
  • Added CLI subcommands to inspect and update Hub settings with revision compare-and-set and --dry-run (scion hub settings get|set|unset|schema), default settings for new projects (scion hub project-defaults get|set|unset), feature experiments (scion hub experiments list|enable|disable|reset), per-project settings (scion project settings get|set|unset), user delegation policies (scion hub delegation), Hub- and project-boundary access tokens (scion hub token list|scopes|create --boundary project|hub), artifact comments (scion artifact comments), and server keyring verification (scion server keys verify|status|check).
• Agent creation, terminal keys, port forwarding, and tunneling (scion create, keys, expose, tunnel):
  • scion create accepts --model and --thinking-level (matching scion start), and --tz <zone> (and --utc) sets the CLI display timezone across commands.
  • scion keys <agent-name> <keystrokes> sends terminal keystrokes (Enter, C-c, Escape, or literal text) to a running agent’s tmux session.
  • scion expose <port> (and scion unexpose) registers an HTTP/WebSocket port inside an agent container with the Hub’s authenticated port proxy (with experimental browser page links behind hub.port_view), and scion tunnel forwards local TCP ports to an agent over an authenticated tunnel.
• Multi-hub project listing and context selection (scion project list, scion use):
  • scion project list aggregates projects across all registered hubs alongside local checkouts (--hub <name>, --refresh, --local).
  • scion use <project> pins an active project context outside a repository checkout so subsequent CLI commands target that Hub project without repeating --project.
• Doctor and Runtime Broker diagnostics (scion doctor, scion runtime-broker status):
  • scion doctor checks Hub connectivity, authentication status, server.trusted_proxies configuration, Cloud Run actAs permissions, Kubernetes RBAC and PVC storage classes, flat placement preflight (flat-placement-preflight), and Runtime Broker command-channel health (broker_command_path).
  • scion runtime-broker status reports Hub API: reachable, connection state (connecting until handshake completion, then connected), and Commands: status per registered Hub.

Security and access

• TLS and single-use nonced HMAC requests between Hub and Runtime Brokers:
  • Off loopback, the Hub requires HTTPS (directly or via server.trusted_proxies) for all Runtime Broker control-channel and heartbeat traffic, paired with timestamped, single-use nonced HMAC signatures (2 MiB payload cap) to prevent replay across broker requests.
• Versioned cryptographic signing rings and sealed secrets (server.secret_rotation):
  • User JWTs, agent JWTs, and Conduit relay admission tokens and peer signatures are signed and verified against versioned key rings with explicit key IDs stored in the Hub’s keyring, supporting key rotation without invalidating in-flight sessions until retired key versions are removed.
  • Hub-stored backups (signing keys, OIDC keyset) and no-backend GitHub App and chat secrets are sealed with the versioned value cipher and audited against the database encryption policy at startup (scion server keys verify).
  • Hub-dispatched agent starts require a short-lived Hub-issued start token verified by the Runtime Broker.
• Recorded delegation chains and intrinsic token-created agent delivery:
  • Every agent records its creator and delegation lineage. User-scoped secrets (--allow-progeny), GCP service-account token minting (gcp_service_account.use), and lifecycle hook tokens are authorized along the recorded delegation chain, and agent delegated credentials can list project agents, skills, and templates with per-item read checks.
  • For agents created from a user access token (scion_pat_...), the agent-only delivery permissions (secret.deliver, env_var.deliver, skill_injection.deliver, and secret.use) are intrinsic to the recorded token-creation edge while the creating user remains an active member of the project (scion.hub.authz.uat_intrinsic), so token-created agents receive shared user secrets and project/Hub/Broker launch material without widening token scopes. See Agents Created from a User Access Token.
• Workspace, NFS, Agent home, and Runtime Broker mount isolation:
  • Runtime Brokers block any mount source reaching broker credentials, state, plugins, or Hub databases (400 control_path_mount), enforce nosuid,nodev and agent/project subtree confinement on NFS mounts, write declarative harness files and skills through symlink-refusing handles, and scrub host git credentials (LC_ALL=C, GIT_CONFIG_GLOBAL=/dev/null, GIT_CONFIG_NOSYSTEM=1, GIT_TERMINAL_PROMPT=0, credential.helper=) on all host-side git operations while enforcing the repository .git/config allow-list (git_config_refused).
• Kubernetes and Cloud Run workload isolation:
  • Kubernetes agent pods run with automountServiceAccountToken: false in all GCP identity modes — using kubernetes_block_service_account in block mode or the namespace default KSA otherwise — so agent workloads do not receive an ambient Kubernetes API token. See Agent Pod Identity.
  • Cloud Run agents stage Hub and harness credentials in an in-memory volume, sign ephemeral OS Login SSH keys scoped to the instance’s service account for exec, and support experimental per-instance service-account assignment (hub.cloudrun_native_identity).
• Granular RBAC permissions, scoped Personal Access Tokens, and notification/log validation:
  • Added project.chat_post (and the project:chat_post PAT scope) separating chat read access from posting in project threads, separated agent.lifecycle from agent.attach and agent.port_access on project admin/owner roles, enforced interactive-session requirements on user- and Hub-scoped secret and environment-variable mutations, validated email notification headers (single-line CR/LF stripping), Teams Bot Framework hosts, and Cloud Logging log-level filters, and added hub.authorization_decision_audit_v2 structured authorization audit logging.

Integrations

• Opt-in pi coding agent harness alongside claude, gemini, codex, and opencode:
  • Added built-in support for the pi harness (harnesses/pi) as an opt-in harness alongside claude, gemini, codex, and opencode, with model alias resolution, colon-preserving model IDs, telemetry hook integration, and scion-omni / scion-pi container image build targets. See Supported Harnesses.
  • Which prebuilt harness container images (scion-claude, scion-gemini, scion-codex, scion-opencode, scion-pi, scion-omni) are published as stable for v0.3.0 and under which registry tags: To be confirmed at release.
• Homebrew formula and container image bootstrap (homebrew-scion):
  • Updated the Homebrew release automation (scripts/release/update-homebrew-formula.sh) for v0.3.0 client and workstation installs, including Linux glibc and gcc dependency notes; see Installing Scion.
  • Whether the stable v0.3.0 release publishes prebuilt container images to ghcr.io/homebrew-scion or another public registry for Homebrew installs, which images are included, and what tags they carry: To be confirmed at release.
• Cloud Run and GKE workload identity and shared storage integrations:
  • Added support for Cloud Run NFS volume mounts (cloudrun-volume) with per-agent NFS workspaces and provisioned Agent homes, GKE shared Filestore/NFS volumes (gke-shared-volume and inline NFS mounts), and experimental Cloud Run native service-account identity (hub.cloudrun_native_identity), flat Cloud Run targets (hub.flat_cloudrun_target), and GKE NFS agent home directories (hub.k8s_nfs_home).
• Lifecycle hooks with verified GCP service-account impersonation and GitHub App project scoping:
  • Outbound http lifecycle hooks mint short-lived OIDC / access tokens for verified GCP service accounts after re-checking the hook writer’s active status, hub.lifecycle_hooks.update permission, and GCP IAM actAs authorization on every invocation. See Lifecycle Hooks.
  • GitHub App installation tokens are scoped to the agent’s own project (or a verified cross-project token-source label re-checked on every mint), and sealed when stored without an external secret backend.