@dinglebear/labby 1.13.3 → 1.17.3

package/README.md

@@ -52,13 +52,11 @@ Labby is centered on the current gateway/operator surface:
   feature-matrix artifacts under
   [docs/generated](./docs/generated/README.md).
 
-The registered services on this branch are exactly `doctor`, `fs`, `gateway`,
-`lab_admin`, `server_logs`, `setup`, and `snippets`. The older
-`marketplace`/`stash`/`acp`/`nodes`/`deploy`/`logs`/`device` product services
-were removed by the "Slim labby gateway host" pass; their domain types survive
-in `labby-runtime`/`labby-apis` but are no longer registered services and have
-no CLI commands. Use the generated catalogs below for the current surface
-instead of copying command or action lists by hand.
+Use the generated service, action, and CLI catalogs below for the complete
+current product surface instead of copying inventories into hand-written
+documentation. Standalone ACP chat, Marketplace/MCP Registry browser, Fleet,
+Deploy, and Stash products remain retired; bounded provider-backed discovery
+through the `artifacts` control-plane service does not restore those products.
 
 ## Quick Start
 
@@ -92,7 +90,17 @@ the [stdio MCP proxy guide](./docs/guides/STDIO_MCP_PROXY.md).
 Linux/macOS:
 
 ```bash
-curl -fsSL https://raw.githubusercontent.com/dinglebear-ai/labby/main/scripts/install.sh | sh
+version=vX.Y.Z
+base="https://github.com/dinglebear-ai/labby/releases/download/$version"
+curl -fSLO "$base/labby-install.sh"
+curl -fSLO "$base/labby-install.sh.sha256"
+gh attestation verify labby-install.sh \
+  --repo dinglebear-ai/labby \
+  --signer-workflow dinglebear-ai/labby/.github/workflows/release.yml \
+  --source-ref "refs/tags/$version" \
+  --deny-self-hosted-runners
+shasum -a 256 -c labby-install.sh.sha256
+LABBY_INSTALL_VERSION="$version" sh ./labby-install.sh
 labby setup
 labby serve --host 127.0.0.1 --port 8765
 ```
@@ -106,19 +114,90 @@ npx -y @dinglebear/labby mcp
 Windows PowerShell:
 
 ```powershell
-irm https://raw.githubusercontent.com/dinglebear-ai/labby/main/scripts/install.ps1 | iex
+$Version = "vX.Y.Z"
+$Base = "https://github.com/dinglebear-ai/labby/releases/download/$Version"
+Invoke-WebRequest "$Base/labby-install.ps1" -OutFile labby-install.ps1
+Invoke-WebRequest "$Base/labby-install.ps1.sha256" -OutFile labby-install.ps1.sha256
+gh attestation verify labby-install.ps1 `
+  --repo dinglebear-ai/labby `
+  --signer-workflow dinglebear-ai/labby/.github/workflows/release.yml `
+  --source-ref "refs/tags/$Version" `
+  --deny-self-hosted-runners
+$Expected = ((Get-Content labby-install.ps1.sha256) -split '\s+')[0]
+if ((Get-FileHash labby-install.ps1 -Algorithm SHA256).Hash.ToLower() -ne $Expected) { throw "installer digest mismatch" }
+$env:LABBY_INSTALL_VERSION = $Version
+& ./labby-install.ps1
 labby setup
 labby serve --host 127.0.0.1 --port 8765
 ```
 
-The install scripts download the requested GitHub Release asset, verify its
-checksum, and install `labby` onto the user PATH. They do **not** perform
+The separately downloaded and attested install scripts resolve an immutable GitHub Release containing the current
+platform asset, require `gh`, verify the archive's attestation against the
+Labby repository, `release.yml`, exact tag, and hosted-runner policy, verify its checksum, and install `labby` onto the
+user PATH. They do **not** perform
 operator provisioning or environment setup. The scripts only install the binary
 (from a release or fallback source build); all first-run provisioning is handled
 inside `labby` via `labby serve` bootstrap and `labby setup`.
 
 Override install behavior with `LABBY_INSTALL_DIR`, `LABBY_INSTALL_VERSION`, or
-`LABBY_INSTALL_REPO`.
+`LABBY_INSTALL_REPO`. Source fallback is off by default. Opt in with
+`LABBY_ALLOW_SOURCE_FALLBACK=1`; a pinned `LABBY_INSTALL_VERSION` is passed to
+Cargo as the exact tag instead of silently building the default branch.
+
+Each successful install retains the verified binary by SHA-256 plus an
+owner-only receipt beneath `<install-dir>/.labby-install/`. At least the prior
+verified artifact remains available when distribution is unavailable. Restore
+it without downloading or changing `$LABBY_HOME`:
+
+```bash
+LABBY_INSTALL_ROLLBACK=1 sh ./labby-install.sh
+```
+
+```powershell
+$env:LABBY_INSTALL_ROLLBACK = '1'
+& .\labby-install.ps1
+```
+
+Rollback switches only the installed executable and receipt. It does not
+downgrade or delete configuration, credentials, databases, or other durable
+state. Inspect the receipt at `<install-dir>/.labby-install/receipt` on Unix or
+`receipt.json` on Windows.
+
+Release qualification can install an already-downloaded candidate without
+network or source fallback by setting `LABBY_INSTALL_LOCAL_BINARY` and its exact
+lowercase `LABBY_INSTALL_LOCAL_SHA256`. The installer copies that input once to
+private staging, verifies the staged bytes, and activates those same bytes. It
+also rehashes every existing cached artifact before reuse. Before changing the
+binary or either receipt, the installer writes a recovery journal beneath
+`.labby-install/`; a later invocation restores the complete pre-install
+snapshot when it finds an interrupted activation. If restoration fails, the
+installer stops and retains the journal for diagnosis.
+
+### Automatic updates on macOS
+
+For a persistent macOS server, enable daily updates in the existing server job:
+
+```bash
+LABBY_SERVICE_AUTO_UPDATE=1 bash scripts/install-macos-service.sh install
+```
+
+This runs `labby serve --auto-update` under launchd and removes the separate
+updater job after the server passes its health check. See the
+[macOS setup instructions](docs/services/SETUP.md#macos-server-and-automatic-updates).
+
+For an installation without a persistent server, use the standalone daily job:
+
+```bash
+labby update --auto-update enable
+labby update --auto-update status
+labby update --auto-update disable
+```
+
+Both modes require Apple Silicon and GitHub CLI (`gh`) for release attestation
+verification. They skip drafts, prereleases, missing platform assets, and versions
+equal to or older than the installed binary. The installer verifies attestations
+and checksums before atomic replacement. No separate language runtime is required.
+Use `labby update --automatic --dry-run` to check without installing.
 
 ### Build From Source
 
@@ -152,14 +231,21 @@ just macos-service-status
 ```
 
 This installs a `launchd` LaunchAgent that keeps Labby listening on
-`127.0.0.1:8765`, restarts it after login or exit, and writes logs under
-`~/.labby/`. Use `just macos-service-restart` after changing service settings
+`127.0.0.1:8765`, restarts it after login or exit, and uses the stable absolute
+`LABBY_HOME` (default `~/.labby`) as both working directory and durable
+configuration root. It never persists the directory from which installation
+was invoked. Logs default to the same root. Use `just macos-service-restart`
+after changing service settings
 or `just macos-service-uninstall` to remove it. The cross-platform
 `just service-install`, `just service-status`, `just service-restart`, and
 `just service-uninstall` bindings select launchd on macOS and systemd on
 Linux. This is suitable for a Tailscale Serve/Funnel route whose OAuth
 callback targets the local gateway.
 
+When overriding the launchd paths, `LABBY_SERVICE_BIN`, `LABBY_STATE_DIR`, and
+`LABBY_HOME` must all be absolute; relative paths fail before the plist or
+service is changed.
+
 ### First Run
 
 For loopback development, `labby serve` can bootstrap a missing bearer token for
@@ -176,7 +262,7 @@ Bootstrap writes these required `setup` keys if no env exists yet:
 - `LABBY_MCP_HTTP_PORT=8765`
 - `LABBY_AUTH_MODE=bearer`
 
-It also enforces secure file creation via Lab's `env_merge` path (`0600` perms on
+It also enforces secure file creation via Labby's `env_merge` path (`0600` perms on
 Unix) and then skips creating anything else until the web wizard runs.
 
 For explicit setup:
@@ -223,7 +309,13 @@ labby mcp
 `labby serve` starts the hosted HTTP runtime: `/v1` product APIs, `/mcp`
 streamable HTTP MCP, auth routes, OAuth relay endpoints, and static Labby web
 assets when an export is available. `labby mcp` is the stdio MCP entrypoint for
-local MCP clients.
+local MCP clients. A client configured to launch `labby mcp` does not need an
+HTTP URL: when a `labby serve` daemon is reachable, the stdio process becomes a
+transparent bridge to that daemon and uses its gateway configuration, upstream
+connections, and OAuth state. If no daemon is found and no explicit target is
+set, it starts a standalone local gateway instead. See the
+[local bridge guide](./docs/surfaces/TRANSPORT.md#local-bridge-to-the-running-daemon)
+for client configuration and `LABBY_SERVER_URL` fail-closed behavior.
 
 ### Manage Upstream MCP Gateways
 
@@ -284,7 +376,7 @@ labby snippets test my-snippet
 ```
 
 Snippets are stored per-user under `$LABBY_HOME` and executed through the
-gateway Code Mode runner, so they can reach exposed upstream tools but not Lab
+gateway Code Mode runner, so they can reach exposed upstream tools but not Labby
 actions. The `snippets` service is gateway-gated: it is unavailable in builds
 without the `gateway` feature.
 
@@ -311,7 +403,7 @@ severity found.
 > from source, manifests, packaging, and CI — not merely feature-gated.
 > `scripts/check-retired-features.sh` guards against reintroduction, and the
 > historical designs are archived under
-> [docs/references/retired-labby](./docs/references/retired-labby/). Plugin
+> [docs/archive/retired-labby](./docs/archive/retired-labby/). Plugin
 > marketplace assets now live in the separate
 > [dendrite](https://github.com/dinglebear-ai/dendrite) repo.
 
@@ -362,17 +454,13 @@ Configuration is split deliberately:
 
 | Data | Location | Examples |
 | --- | --- | --- |
-| Secrets and endpoint values | `~/.labby/.env` | `LABBY_MCP_HTTP_TOKEN`, `LABBY_GOOGLE_CLIENT_SECRET`, upstream bearer token env values |
-| Preferences | `config.toml` | transport, CORS, auth mode, workspace root, gateway spawn guard, and upstream behavior |
-
-`config.toml` is searched in this order:
-
-1. `./config.toml`
-2. `~/.labby/config.toml`
-3. `~/.config/labby/config.toml`
+| Secrets and endpoint values | `$LABBY_HOME/.env` | `LABBY_MCP_HTTP_TOKEN`, `LABBY_GOOGLE_CLIENT_SECRET`, upstream bearer token env values |
+| Preferences | `$LABBY_HOME/config.toml` | transport, CORS, auth mode, workspace root, gateway spawn guard, and upstream behavior |
 
-Startup loads the first `config.toml`, initializes tracing, then loads
-`~/.labby/.env` and a CWD `.env` if present. Runtime precedence is:
+`LABBY_HOME` selects the one authoritative configuration and durable-state
+root and must be absolute. It defaults to `~/.labby`; Labby does not implicitly
+read CWD or XDG fallback files. Existing process environment values win over
+values loaded from the selected `.env`. Runtime precedence is:
 
 1. CLI flags
 2. Environment variables
@@ -386,7 +474,9 @@ Useful environment variables:
 | `LABBY_MCP_HTTP_TOKEN` | Static bearer token for protected admin/API/MCP routes. |
 | `LABBY_AUTH_MODE` | `bearer` or `oauth`. |
 | `LABBY_PUBLIC_URL` | Public base URL for OAuth metadata, issuer/audience, callbacks, and allowed-host derivation. |
-| `LABBY_GOOGLE_CLIENT_ID` / `LABBY_GOOGLE_CLIENT_SECRET` | Google OAuth credentials for OAuth mode. |
+| `LABBY_AUTH_PROVIDER` | Inbound OAuth identity provider: `google` (stable) or `authelia` (open beta). |
+| `LABBY_GOOGLE_CLIENT_ID` / `LABBY_GOOGLE_CLIENT_SECRET` | Google credentials when Google is selected. |
+| `LABBY_AUTHELIA_ISSUER_URL` / `LABBY_AUTHELIA_CLIENT_ID` / `LABBY_AUTHELIA_CLIENT_SECRET` | Authelia OIDC configuration; see the pinned registration contract in the OAuth guide. |
 | `LABBY_AUTH_ADMIN_EMAIL` | Bootstrap admin email; required in OAuth mode. |
 | `LABBY_OAUTH_ENCRYPTION_KEY` | Base64 32-byte key required for encrypted upstream OAuth credentials. Rotation requires reauthorizing affected upstreams. |
 | `LABBY_WEB_ASSETS_DIR` | Override static Labby export directory. |
@@ -396,8 +486,8 @@ Useful environment variables:
 | `LABBY_ACTOR_KEY_SECRET` | Stable secret for redacted actor correlation in logs. |
 | `LABBY_ADMIN_ENABLED` | Runtime opt-in for the `lab_admin` tool. |
 
-Bearer auth is an operator/admin shortcut for Lab routes. Public protected MCP
-routes validate route-scoped Lab OAuth JWTs; do not treat `LABBY_MCP_HTTP_TOKEN` as
+Bearer auth is an operator/admin shortcut for Labby routes. Public protected MCP
+routes validate route-scoped Labby OAuth JWTs; do not treat `LABBY_MCP_HTTP_TOKEN` as
 a public resource credential.
 
 When driving the web UI with automation while OAuth is enabled, pass the bearer
@@ -533,20 +623,28 @@ recommended agent gateway runtime.
 
 ### Dev Container
 
-The Compose stack is a trusted local operator environment, not a hardened
-generic deployment. It bind-mounts Labby state, the repository, and built web
-assets; secrets are loaded from the mounted `/home/labby/.labby/.env`. The image
-installs pinned Claude, Codex, and Gemini CLIs for stdio upstreams that invoke
-provider tools. It does not install ACP adapters or mount ACP-specific state.
+The development Compose stack mirrors the production process controls: a
+read-only root filesystem, dropped capabilities, `no-new-privileges`, loopback
+port binding, bounded logs, and named volumes for durable state and data. It
+also bind-mounts the source repository read-only so locally built web assets are
+visible without rebuilding the image. The clean-checkout defaults mount the
+tracked, non-secret `config/config.example.toml` and `config/.env.example`.
+Set `LABBY_CONFIG_FILE` and `LABBY_ENV_FILE` to select local runtime files;
+Compose mounts both read-only at their canonical paths beneath `$LABBY_HOME`. Labby-owned runtime
+state remains writable in the surrounding `labby-home` named volume. Startup logs and the
+setup settings state report `/home/labby/.labby/config.toml` as the effective
+source. The image installs pinned Claude,
+Codex, and Gemini CLIs for stdio upstreams that invoke provider tools.
 
 ### Releases
 
 Release Please maintains the version/changelog pull request and creates the
-stable tag plus draft GitHub release when that pull request merges. Publishing
-the release triggers the heavy GitHub-hosted x86_64 workflows. They build Linux
-and Windows archives with checksums, build and scan the GHCR image, build and
-smoke the Incus image, publish the npm launcher, and publish Labby's
-`server.json` metadata to the official MCP Registry.
+stable tag plus draft GitHub release when that pull request merges. The stable
+tag triggers the heavy GitHub-hosted candidate workflow. It builds Linux,
+macOS, and Windows archives with checksums, builds and smokes the Incus image,
+publishes the npm launcher, and publishes Labby's
+`server.json` metadata to the official MCP Registry. Only after qualification
+and publication succeed does the workflow promote the draft GitHub release.
 
 ### Plugin Setup
 

package/lib/platform.js

@@ -23,7 +23,17 @@ function targetFor(platform = process.platform, arch = process.arch) {
     };
   }
 
-  throw new Error(`Unsupported platform ${platform}/${arch}. Supported targets: linux/x64, win32/x64.`);
+  if (platform === "darwin" && arch === "arm64") {
+    return {
+      asset: "lab-aarch64-apple-darwin.tar.gz",
+      binary: "labby",
+      archiveType: "tar.gz",
+    };
+  }
+
+  throw new Error(
+    `Unsupported platform ${platform}/${arch}. Supported targets: linux/x64, darwin/arm64, win32/x64.`,
+  );
 }
 
 function releaseVersion(env = process.env) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dinglebear/labby",
-  "version": "1.13.3",
+  "version": "1.17.3",
   "license": "AGPL-3.0-only",
   "description": "Rust MCP gateway with Code Mode, authentication, setup, logs, CLI, HTTP API, and operator web UI.",
   "homepage": "https://github.com/dinglebear-ai/labby#readme",

package/scripts/check-package.js

@@ -318,7 +318,7 @@ function supportedTargets(platform) {
   const tuples = [
     ["linux", "x64"],
     ["win32", "x64"],
-    ["darwin", "x64"],
+    ["darwin", "arm64"],
     ["linux", "ppc64"],
   ];
   const targets = [];