Skip to content

Week of October 26 -- November 1, 2026

This week Scion hardened the Hub and Runtime Broker boundary and workspace isolation: Hub–Runtime Broker traffic now requires TLS off loopback (server.trusted_proxies) with single-use nonced requests, host-side git runs without host credentials and checks repository git config before start, and Runtime Brokers refuse mounts that reach their 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 now 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.


1. Hardened Hub–Runtime Broker Transport, Host Git and Workspace Mounts

Section titled “1. Hardened Hub–Runtime Broker Transport, Host Git and Workspace Mounts”

The Hub and the Runtime Broker now refuse plaintext connections to non-loopback endpoints, minting Runtime Broker secrets and join tokens only over TLS or from the same host and reading forwarded headers only from server.trusted_proxies (defaulting to 127.0.0.1 and ::1 when unset), while each signed Hub request requires a nonce, is served once within the clock-skew window, and caps signed request bodies at 2 MiB (413 payload_too_large). Host-side git operations run through the guarded entry point with LC_ALL=C and no longer use host credential helpers, askpass, ~/.netrc, TLS client certificates, Kerberos credentials or SSH identities, and agent starts on Docker, Podman and Apple runtimes verify repository, worktree and submodule git configs against an allow-list before starting. Runtime Brokers refuse mounts whose host source reaches their credentials, local settings, identity and state files, plugins or co-located Hub database — stopping running agents that fail the periodic check — and require a .scion directory or marker inside explicit project paths (409 project_path_not_initialized). NFS mounts made by a Runtime Broker require nosuid,nodev (503 nfs_unavailable otherwise) and are confined at start on Kubernetes, Cloud Run and Docker/Podman/Apple to the agent’s allowed tree, while Kubernetes agent pods set automountServiceAccountToken: false in every GCP identity mode.

2. Delegation-Chain Authorization, Keyring-Signed JWTs and Interactive Secret Management

Section titled “2. Delegation-Chain Authorization, Keyring-Signed JWTs and Interactive Secret Management”

Agent reads and lists of user-scope secrets, start and restart secret delivery, and GCP service-account token minting (gcp_service_account.use, with boot migration sa_assignment_legacy_backfill backfilling legacy rows from recorded delegation edges) now enforce the recorded parent ceiling along the agent’s delegation chain, and lifecycle hooks confirm that the hook’s writer still exists, is active and may still use the service account before minting a token. Agents created from a user access token now receive secret.deliver, env_var.deliver, skill_injection.deliver and secret.use intrinsically on their token-recorded edge, and agents adopted from before recorded delegation at the baseline or readonly role receive their owner’s user secrets again at start and restart. On Hubs with a server keyring file, agent and user JWTs and conduit relay tokens are signed by the active generation with key IDs, Hub-stored backups use the versioned value cipher under the database encryption policy, and Hub-dispatched starts require a Hub-issued token (agent.ErrNoHubToken otherwise, with SCION_AUTH_TOKEN stripped from the start environment). User- and Hub-level environment variables and secrets now require an interactive login (refusing scoped access tokens with CREDENTIAL_MANAGEMENT), and with dev auth enabled the web server creates sessions only from short-lived, single-use launch links (POST /auth/dev-launch, GET /auth/dev-signin, scion server open [--print]) and refuses a non-loopback Hub host when the web server is disabled.

3. Shared NFS Project Storage Across Runtimes, Hub-Signed Bootstrap and Graduated Defaults

Section titled “3. Shared NFS Project Storage Across Runtimes, Hub-Signed Bootstrap and Graduated Defaults”

Shared server.project_storage now supports every project shape on Kubernetes (with agent-scoped workspaces on the share, or direct inline NFS mounts when shares[0].pv_name is unset) and gives clone-per-agent agents on cloudrun their own NFS workspace alongside pre-checked CPU and memory limits, while Runtime Brokers without Google Cloud credentials can bootstrap a Hub-managed workspace from a GCS Hub using short-lived, per-file signed URLs. Storage settings are validated in one place (422 storage_invalid), profiles that still set shared_dir_storage_backend(s), home_storage_backend or home_storage_leaf are refused with 422 at agent start, a share the Runtime Broker cannot see returns 503 project_storage_unavailable and reports as degraded in /healthz, and on nfs the Hub’s /readyz checks the share itself and the Hub is the sole remover of a deleted project’s shared tree. Asynchronous agent create (hub.async_agent_launch), chat attachment artifacts (hub.attachment_artifacts, wherever the artifact service is ready) and starred chat messages (web.chat_starred_messages, expanded to direct messages, a ?messages=starred view and a chat-star-reconcile maintenance operation) are now enabled by default. An important fix also restores starting, resuming and restarting existing agents by sending environment classifications on start and restart over both transports as create does.

4. Native Windows Client CLI, Single-Node Hub Self-Update and Expanded Hub CLI

Section titled “4. Native Windows Client CLI, Single-Node Hub Self-Update and Expanded Hub CLI”

scion now builds and runs natively on Windows (amd64 and arm64) as a Hub client for ssh, ssh-config, tunnel and VS Code, verifying owner-only permissions on private files and shipping Windows zips in SHA256SUMS. Single-node VM Hubs installed by deploy.sh under /opt/scion support update-binary with pinned GitHub asset URLs, per-asset SHA256 verification and automatic updates of installed Runtime Broker plugins (~/.scion/plugins/broker), alongside confirmed downgrades (409 downgrade_requires_confirmation) that keep five database and settings snapshots and a boot-failure guard that rolls back a crash-looping release. The CLI adds scion hub settings get/set/unset/schema (with compare-and-set and --dry-run), scion hub project-defaults get/set/unset, scion hub experiments list/enable/disable/reset, and user-mode scion hub delegation commands, while scion secret get (--value for the value) and scion secret list replace sciontool secret in agent mode. Recurring schedules can now name an IANA time zone for next-run calculation, count limits (max_turns, max_model_calls) treat 0 as Unlimited across the API, CLI and web UI, and a new opt-in pi container-script harness bundle is available pinned to 1.3.0.


  • Hub–Runtime Broker TLS transport, server.trusted_proxies and nonced signed requests (#4384, #4404, #4227, #4274, #4282): The Hub and the Runtime Broker refuse plaintext connections to non-loopback endpoints, and Runtime Broker secrets and join tokens are minted only for requests arriving over TLS or from the same host. Forwarded headers (and the relay public listener) are trusted only from server.trusted_proxies; when unset, a proxy on the same host (127.0.0.1, ::1) is trusted with a startup warning, and an explicit list (including []) is used exactly. Refusals name server.trusted_proxies in the 403 details, Hub error and Runtime Broker log and raise a health and scion doctor finding. Each signed Hub request must carry a nonce and is served once (repeats within the clock-skew window get 401 "request already served"), and signed request bodies are capped at 2 MiB (413 payload_too_large). Deployments with a plaintext, non-loopback internal conduit relay hop must follow the upgrade order in the separate-relay guide.
  • Host-side git uses no host credentials and agent start checks repository git config (#4322, #4327, #4376, #4352, #4387): On Docker, Podman and Apple runtimes, the repository git config and the worktree and submodule layers an agent can reach are checked before start; starts are refused when a layer sets a key outside the allow-list (such as core.sshCommand, core.hooksPath, core.editor, filter drivers, url.<base>.insteadOf, or include/includeIf), naming the key (never its value) and config file to fix. Git remote operations run by the Hub or a Runtime Broker (including the backstop clone and agent-start clones) no longer use the host’s credential helpers, askpass, ~/.netrc, TLS client certificates, Kerberos credentials or SSH identity: without a project git secret they run anonymously, with one only that secret is offered to the project’s recorded remote, and SSH repository URLs require a project secret.
  • Runtime Broker control-path mount refusals, explicit .scion paths and template file confinement (#4331, #4401, #4400): Agent mounts whose host source reaches the Runtime Broker’s credentials, local settings, host identity and state, plugins or co-located Hub database are refused (following symlinks) at Runtime Broker start, agent create and start, and container creation, and a periodic check stops running agents whose binds fail it. Explicit project paths given to a Runtime Broker require a .scion directory or marker inside the path (refusing a .scion symlink pointing outside it), failing with 409 project_path_not_initialized instead of mounting the parent directory. Template agent_instructions and system_prompt files must be regular files of at most 4 MiB inside the template directory with symlinks not followed; a single-line value must be a relative path (a value with a line break is inline text), and a file that exists but cannot be read this way fails with an error instead of being treated as inline text.
  • NFS project storage readiness, nosuid,nodev, inline NFS mounts and retired storage overrides (#4458, #4377, #4342, #4354, #4242): On the nfs project storage backend, the Hub is the sole remover of a deleted project’s shared tree and its workspace_storage readiness check verifies the share itself (project_storage_tree is retired for nfs): a Hub with projects that cannot see the share or its subpath_root answers 503 on /readyz, reports unhealthy on /healthz, and if the Hub cannot see the share on project delete it returns 200 with storageKept instead of 204 while Runtime Brokers keep their project directory while agents remain (409). Every NFS mount made by a Runtime Broker ends with nosuid,nodev, and agent create, start and restart on local-container runtimes are refused with 503 nfs_unavailable when the project share lacks either flag. With project_storage NFS and no shares[0].pv_name, Kubernetes agent pods mount the share directly (requiring the Runtime Broker to mount the export writably at mount_root/<share id>, and refusing Agent homes on NFS). Profiles that still set shared_dir_storage_backend(s), home_storage_backend or home_storage_leaf are refused with 422 at agent start instead of being ignored.
  • Hub-issued tokens required on start, per-item secret delivery and recorded service-account ceiling (#4248, #4294, #4318, #4231, #4397): A Hub-dispatched start takes the agent’s Hub token only from the token the Hub issued, stripping SCION_AUTH_TOKEN from the start environment; a start without one fails with agent.ErrNoHubToken before any container starts, and a restart without one ends with the agent stopped. Agent start and restart apply the same per-item authorization as runtime secret reads and refuse the start when a selected secret value cannot be read (agents whose delegation records predate current provenance keep their launch material under a logged exception). The agent GCP identity and access token endpoints and the GCS link proxy check gcp_service_account.use against the service account’s recorded parent authority before minting (ceiling_provenance_missing otherwise; boot migration sa_assignment_legacy_backfill backfills missing rows from recorded delegation edges). GitHub App installation tokens are minted only for the agent’s own project.
  • Interactive login for user/Hub secrets and dev auth loopback/launch links (#4319, #4094, #4112): User- and Hub-level environment variable and secret operations accept only CLI login, web session or workstation dev auth credentials (and Hub scope also requires an unscoped local platform admin); scoped access tokens are refused with a CREDENTIAL_MANAGEMENT error pointing to scion hub auth login (project and Runtime Broker scopes are unchanged). With dev auth enabled, the web server creates a session only from a short-lived, single-use link (POST /auth/dev-launch, then GET /auth/dev-signin, opened by scion server start or scion server open [--print]; 404 when dev auth is off), and with the web server disabled scion server start refuses a non-loopback Hub host.
  • Keyring-signed JWTs and database encryption policy at startup (#4243, #4145): On Hubs with a server keyring file, agent and user JWTs (access, refresh, CLI and test-login) are signed by the active generation with its key ID, accepted only by the generation that signed them with no fallback for unknown key IDs, and the Hub refuses to start if the keyring is unusable. Hub-stored backups (signing keys, OIDC keyset) use the shared versioned value cipher, audited before any write at startup, and the Hub refuses to start if the local keyring cannot satisfy the database encryption policy.
  • Agent pods disable Kubernetes API token automount and placement is checked on save (#4362, #4295, #4415): Kubernetes agent pods are created with automountServiceAccountToken: false in every GCP identity mode (Workload Identity is unaffected and pods keep their ServiceAccount). Flat Runtime Broker targets add node_selector, tolerations and runtime_class_name and refuse starts before any side effect on mismatch (scion doctor flat-placement-preflight flags affected agents). Saving runtimes and profiles checks placement across entries in one guarded transaction (422 on newly introduced problems, warning on stored ones, 409 on conflict).
  • max_turns: 0 means Unlimited, scion secret in agent mode and single-node VM layout (#4356, #3985, #4179): Count limits (max_turns, max_model_calls) now treat 0 as Unlimited (unset inherits, a positive value caps, and Hubs refuse 0 with 422 when the Runtime Broker lacks unlimitedCountLimits). Inside agents, sciontool secret get and list moved to scion secret get (--value prints the value; metadata stays the default and --format json stays metadata-only) and scion secret list. Single-node VM Hubs without a repository path that relied on blanket sudo report self-update as unsupported until migrate-layout is run.
  • Settings write error envelope, live authorized_domains, root-level session checks and chat totalCount (#4442, #4424, #4374, #4307): Settings write APIs return 422 validation_error with field-level details.errors (instead of 400 validation_failed), 409 revision_conflict on a stale revision, and 400 on an unreadable body. On database-backed Hubs, saved server.auth.authorized_domains takes effect live and at startup (SCION_SERVER_AUTH_AUTHORIZEDDOMAINS ranks first, then saved, then settings.yaml, refusing saves or resets that would block the caller with 422). Only files in web/public/ skip the web session check at root-level paths (other root paths redirect browsers to sign-in and return 401 to other clients, including /robots.txt), and chat history and interagent pages always return totalCount: 0.
  • Delegation-chain ceilings for user secrets, service accounts and lifecycle hooks (#4229, #4234, #4231, #4230, #4383, #4272): Agent reads and lists of user-scope secrets, start and restart secret delivery, and GCP service-account token minting (gcp_service_account.use, with boot migration sa_assignment_legacy_backfill) enforce the recorded parent ceiling along the agent’s delegation chain, and lifecycle hooks confirm that the hook’s writer still exists, is active and may still use the service account before minting an access token. Agents created from a user access token receive secret.deliver, env_var.deliver, skill_injection.deliver and secret.use intrinsically on their token-recorded edge, and agents adopted from before recorded delegation at the baseline or readonly role receive their owner’s user secrets again at start and restart.
  • Keyring-signed JWTs, conduit relay tokens and sealed secrets (#4243, #4355, #4145, #4470, #4465): On Hubs with a server keyring file, agent and user JWTs and conduit relay admission tokens and relay-peer signatures use the keyring’s versioned signing ring with key IDs (without a keyring file, JWTs are accepted only with an absent or legacy key ID, and unversioned relay values only from legacy generations). Hub-stored backups use the versioned value cipher under the database encryption policy, GitHub App and chat secrets stored without a secret backend are sealed in managed ring mode, and separate relays receive grant key updates immediately instead of waiting for the 5-minute refresh.
  • User access token role changes, user deletion and tighter token checks (#4365, #4443, #4439, #4438, #4319): User access tokens can change roles with user:promote (member and viewer only) and delete users with user:delete under Hub-level checks, while user reads by token require user.read on the Hub user record, access-constraint preview tokens are accepted only for their own constraint, and constraint window changes require relaxation authority. User- and Hub-level environment variable and secret management requires an interactive login.
  • Host-side git and repository clone hardening (#4306, #4376, #4352, #4387, #4378, #4381, #4379, #4358, #4414, #4398, #4290, #4238): The Hub validates project clone URLs, refuses local paths and file transport, and offers the project’s git token only to its recorded remote (never on the Runtime Broker’s shared-workspace backstop clone). Host git refuses empty or option-leading argument lists, pins discovery to the resolved directory (including the after-run check), runs with LC_ALL=C, and routes the workspace probe, shared-workspace pull/clone fallback, worktree and branch lookups through the guarded host git door without host credentials. Private .git/config copies into agents now also strip client TLS key and certificate paths and other credential-bearing keys.
  • Workspace, NFS and Agent home confinement (#4331, #4450, #4463, #4455, #4221, #4395, #4332, #4312, #4429, #4133, #4245): Runtime Brokers refuse mounts reaching their control files and confine NFS mounts at agent start across Kubernetes, Cloud Run and Docker/Podman/Apple to the agent’s allowed set (refusing the NFS export root, parent directories or another agent’s or project’s tree). Kubernetes file placement re-verifies each created path component after mkdir, the declarative harness reads and writes instructions and system prompts through an Agent home handle that refuses symlinks and outside paths, sciontool harness provision checks path prefixes on a separator boundary, harness-config collection reads stay inside their directory, shared project tree cleanup removes only the canonical location, and transfer and artifact downloads verify hashes before writing and refuse redirect hops (Contributor: Ravshanbek Nazarov).
  • Runtime Broker credentials, proxy auth checks, port proxy and redaction (#4097, #4248, #4294, #4347, #4329, #4325, #4207, #4454, #4326, #4388, #4263, #4393): Deleting a Runtime Broker deletes its HMAC secret and join token in the same transaction (removing orphaned credentials at startup), the Hub sends a Runtime Broker only the project credentials an agent’s GitHub skills can use, the deprecated embedded Runtime Broker registration returns secretKey only when it mints the first secret, GET /runtime-brokers?projectId=X hides LocalPath from non-readers, and integration config responses omit all Hub-managed settings including the database URL and driver. Behind auth.mode: proxy, state-changing browser API requests are checked for expected request properties and content type (403 or 415). The port proxy strips internal Hub authentication and identity headers before forwarding to an agent’s exposed port, workspace files, chat attachments, GCS links and agent pages receive dedicated Permissions-Policy and sandbox headers, and the CSP report endpoint always answers 204 with per-client rate limiting (20 requests/s, burst 200, up to 100 reports per request).
  • Asynchronous agent create on by default and existing-agent start fix (#4334, #4338, #4223): hub.async_agent_launch is now enabled by default and can be toggled in Experiments without a restart. Starting, resuming and restarting an existing agent now sends the agent’s environment classifications over both transports as create does (fixing a regression that broke starting existing agents), and a failed launch report arriving after the agent reported running now fails and cleans up the launch instead of answering as completed.
  • Shared NFS project storage across Kubernetes and Cloud Run, plus Hub-signed bootstrap (#4219, #4299, #4292, #4265, #4453, #4433, #4394, #4459): On shared backends, Runtime Brokers read a Hub-managed project’s configuration from the project root, Agent homes on Kubernetes and Cloud Run share one path shape (migrating stopped Cloud Run agents’ home and secret paths automatically), agent create works for every project shape on Kubernetes with agent-scoped workspaces on the share, and clone-per-agent agents on cloudrun get their own NFS workspace and pre-checked CPU and memory limits. Runtime Brokers without Google Cloud credentials can bootstrap a Hub-managed workspace using short-lived, per-file signed URLs from a GCS Hub (staged before placement), and scion start against a remote Runtime Broker collects local git-less project files from the workspace root and removes the provisioning agent if upload fails.
  • Unlimited count limits and cleared resource sub-fields (#4356, #4419, #4457, #4411): Count limits (max_turns, max_model_calls) support 0 as Unlimited (null clears on project settings PUT and negative values are refused), with Unlimited and Clear controls on the Project Settings and Agent Edit pages. Clearing a stored resources sub-field through config PATCH now takes effect at the next start on Runtime Brokers with the clearedResourceSubfields capability instead of waiting for reincarnation.
  • Stopped and suspended agents free project quota slots (#4441): Stopping or suspending an agent frees its slot in max_agents_per_project; resume, wake, restart and reincarnate at a full limit are refused with a specific message, and the admin quotas page shows the enforced count.
  • Opt-in pi harness, Copilot CLI compatibility and SCION_HARNESS tracking (#4353, #4367, #4217, #4218, #4281): A new opt-in container-script harness bundle for pi (pinned to 1.3.0) preserves colons in model IDs (Ollama tags, Bedrock versions) while stripping only pi thinking suffixes. Copilot agents drop the removed --no-remote flag (keeping remote sessions off via settings) and use a readiness settle delay so agents started without a task no longer wait 90 seconds for their first message, and container SCION_HARNESS follows the launched harness after a harness-config switch.
  • Kubernetes start status, sciontool metadata backoff and skill/template lookups (#4222, #4220, #4277, #4296, #4380, #4434, #4456, #4151, #4208, #4311, #4310): Copied-home Kubernetes runtimes stay in starting until Run returns, and preempted or evicted pods report a start error naming the Kubernetes reason. sciontool’s metadata server caches refused GCP credentials with capped backoff and isolates concurrent identity-token fetches across audiences. Env-gather hubHas[].scope labels follow shared env scope precedence, agent delete and forced user delete preserve 409 placement refusal codes, auto-suspend revokes delegation grants before releasing the claim, Linked project template imports resolve from the checkout root (Contributor: Matt Van Horn), and content-addressed v1 skill lookups resolve only to the oldest published or deprecated matching version.
  • Starred messages and attachment artifacts on by default (#4226, #4239, #4241, #4300, #4268, #4314, #4293, #4225): web.chat_starred_messages is enabled by default, extending stars to direct messages, adding a ?messages=starred view and a Starred rail filter, preserving stars when a conversation becomes a topic, cleaning them up on message or user delete, and adding a chat-star-reconcile maintenance operation. hub.attachment_artifacts also defaults on wherever the artifact service is ready (including workstation and single-node Hubs with local blob storage), attachment-only chat messages with no text are stored cleanly, and scion message --attach warns when falling back to scratchpad staging.
  • Send receipts, inbox claims, chat UI and Telegram replies (#4462, #4210, #4305, #4346, #4315, #4206, #4308, #4337, #4444, #4427, #4410): Message send responses include conversation_id (printed by the CLI with the message ID), agent-to-user DM responses return the stored message_id and timestamp, soft-deleted target agents are treated as unknown on message send, and the Runtime Broker inbox write script claims messages with an exclusive file create instead of mkdir. Each chat bubble keeps its More actions button visible (including on phones), the members sidebar folds People and Agents sections, opening the quick switcher focuses its search box on phones, chat messages render through a single sanitizing markup boundary, new message indexes speed up opening agent DMs on large Hubs, the hourly failed-message purge deletes in chunks of up to 500 rows, and Telegram group-chat error replies are sent as plain text threaded to the sender’s message.

☁️ Runtime Brokers, Settings & Operations

Section titled “☁️ Runtime Brokers, Settings & Operations”
  • Single-node VM self-update, Runtime Broker plugin updates and confirmed downgrades (#4179, #4371, #4440, #4289): deploy.sh installs versioned releases under /opt/scion with current and previous symlinks, and update-binary installs a target version using pinned GitHub asset URLs, per-asset SHA256 checks, preflight checks, boot reconciliation and a default notify update_policy, while also updating installed Runtime Broker plugins (~/.scion/plugins/broker) atomically from the same release. Older releases can be installed after typed confirmation (409 downgrade_requires_confirmation; refused below the downgrade floor or on non-SQLite stores), with each update keeping five database snapshots and settings copies and a deploy.sh boot-failure guard rolling back crash-looping unverified releases. deploy.sh --delete removes the Hub service account’s project IAM bindings before deleting the account.
  • Runtime Broker command-path health, version mismatch flags and startup checks (#4420, #4186, #4471, #4417, #4445, #4399, #4426): Runtime Broker health reports whether its control channel to each Hub works (control_channel), the Hub health summary (broker_command_path), scion doctor and scion runtime-broker status surface Runtime Brokers that are online but cannot receive commands, and update-binary and rebuild-server warn about unset required settings such as server.trusted_proxies. Runtime Broker pages, the health dashboard and the list/get APIs (versionStatus) flag version mismatches against the Hub. Runtime Brokers connect to the Hub before checking non-active profile runtimes in the background (returning a retryable 503 when a stored profile’s runtime is missing), keep stored profiles across empty embedded re-registrations, receive connected as the first control-channel frame with PTY frames scoped to the opening connection, and use a 180s Hub-to-Runtime Broker request limit (210s Runtime Broker write timeout, 4-minute CLI create timeout).
  • Project storage validation, Kubernetes placement preflight and Role guidance (#4340, #4320, #4321, #4328, #4363): Storage settings are validated in one place with field-level errors (422 storage_invalid), a share the Runtime Broker cannot see returns 503 project_storage_unavailable and marks /healthz degraded, and the Runtime Brokers area shows each Runtime Broker’s reported project storage layout and any mismatch with the Hub. scion doctor scans legacy runtimes, profiles and local agents for Kubernetes placement problems (scion hub brokers info shows placement, and profile conversion splits profiles with differing details into separate instances), and recommends a namespaced Kubernetes Role holding only what the Runtime Broker uses.
  • Per-schedule time zones and pause on user delete (#4467, #4364): Recurring schedules can name an IANA time zone (via CLI flag or the web schedule form) used to compute the next run with documented daylight saving handling, while API timestamps stay UTC and an empty zone means UTC. Deleting a user pauses schedules whose recorded authority is that user with creator_deleted across every project without blocking the delete.
  • Settings merges, database diagnostics and routing fixes (#4333, #4446, #4431, #4291, #4452, #4278, #4285, #4201): Server config saves merge runtime entries key by key and validate resource quantities, unversioned settings.yaml files using v1 placement keys are detected as v1, and Hub startup moves a cloned project identity’s config only when it belongs to the same project. The Hub logs rate-limited warnings when a store transaction holds a connection over 2s or a request waits over 1s (with hold, wait and commit histograms), conduit ingress counts pending placements to spread bursts across relays and routes eligible external-relay dials through ingress without double-nonce refusals, and unknown sub-paths under /api/v1/users/{id} return 404.
  • Chat retention (#4385): Behind hub.chat_retention, a Hub-admin chat_retention settings section (messages_retention_days) and a paced sweeper delete old messages along with their attachments, mentions and stars on SQLite and Postgres, recording per-project counts without message content and marking where retained history starts and when replied-to messages are [no longer available].
  • Port view for multi-file web apps (#4348, #4388, #4403): Behind hub.port_view, opening an agent’s forwarded port over conduit or the port-forward tunnel sends the browser to a short-lived page link through which stylesheets, scripts, fetches and WebSockets load as the signed-in user, with page view metrics and updated scion expose guidance.
  • Forced user delete cascade (#4284): Behind hub.user_delete_force_cascade, DELETE /api/v1/users/{id}?force=true revokes the user’s roles, tokens and delegations, stops their agents and removes the user, with per-agent progress at GET /api/v1/users/{id}/deletion and a Force delete dialog in the web UI.
  • Held agent edits re-checked on start (#4409): Behind hub.agent_edit_held, held edits on a running agent stay pending until a start applies them, at which point the Hub re-checks that the saver may still edit the agent (discarding and auditing edits from savers who lost permission, or refusing with 503 if undecided).
  • Server key status report, delegated agent list and skill content hash v2 (#4423, #4451, #4195): Behind server.secret_rotation, GET /api/v1/admin/keys/status and scion server keys status|check report keyring, signing and encryption ring status, deadlines and readiness without key material. Agent delegated credentials can list agents within their grant boundary with per-item read checks and sealed cursors, and behind hub.skill_content_hash_v2 skills gain a contentHashV2 covering path, normalized mode and file hash while accepting pinned hashes in either form.
  • Native Windows client CLI (#4098, #4205, #4209): scion builds and runs on Windows (amd64 and arm64) as a Hub client for ssh, ssh-config, tunnel and VS Code (other commands fail with a clear "not supported on Windows" error), verifying owner-only permissions on private files with retry on concurrent replacement, and shipping Windows release zips in SHA256SUMS.
  • scion hub settings, project-defaults, experiments and delegation commands (#4437, #4449, #4196): scion hub settings get/set/unset/schema manages Hub server configuration with per-section revision compare-and-set and secret-masking --dry-run; scion hub project-defaults get/set/unset and scion hub experiments list/enable/disable/reset manage project defaults and experiments; and scion hub delegation create/list/get/revoke/revoke-all manages agent delegations from user mode, backed by the hubclient agent delegation SDK.
  • scion secret in agent mode and scion server open (#3985, #4094): scion secret get (--value for the secret value; metadata by default and --format json metadata-only) and scion secret list are available in agent mode in place of sciontool secret, and scion server open [--print] mints a single-use dev sign-in launch link on demand.
  • API client and transfer hardening (#4049, #4125, #4138, #4168, #4170, #4253, #4250): The API client and transfer helpers reject non-2xx and unrecognized upload/download responses with bounded error reads, honor canceled contexts before file I/O, apply manifest options on every build, and guard nil receivers, headers, responses and HTTP clients (Contributor: Ravshanbek Nazarov).
  • Kubernetes runtime and project service-account editors (#4339, #4373): The admin Runtimes editor now edits Kubernetes placement and identity fields (node selector, tolerations, service account mappings, runtime class and priority class), and Project Settings adds an editor for the per-profile default GCP service account map.
  • Artifact review editor speed, inline comment editing and pinned toolbar (#4254, #4236, #4335, #4413, #4406, #4422): The Markdown review editor (experimental) opens large documents about ten times faster with Source view fallback for very large files, supports suggestions and comments in list items and table cells while preserving Markdown formatting, fixes task lists, strikethrough and theme colors, lets authors click their own comment badges to edit or clear them, opens links in a new tab on Cmd/Ctrl-click or middle click, adds an in-place Refresh button on the artifact page, and keeps the review toolbar pinned while scrolling with a 44px Comment tap target on phones.
  • Post-sign-in return navigation and modal handling (#4228, #4287, #4405, #4389): Signing in with a web OAuth provider returns to the originally requested same-site path and query (falling back to the path without its query when the URL exceeds the session cookie limit), and opening a pane dialog in the terminal view closes the Jump to agent palette so two modals are never open at once.