Ship a zero-node Core installer with opt-in local sandboxes

CONTRIBUTING.md

@@ -560,8 +560,8 @@ does not qualify its isolation or enable public creation.
 
 ### Optional single-host sandbox suspension
 
-Each Core deployment enables exactly one sandbox provider, selected at setup:
-Docker or microsandbox. Keep both adapters but reject multiple provider entries,
+A Core deployment may run without a sandbox provider. When enabled, exactly one
+sandbox provider is selected at setup: Docker or microsandbox. Keep both adapters but reject multiple provider entries,
 legacy default-provider maps and engine-based placement. Harness selection is
 independent. The configuration has one installation UUID, one provider kind and
 one backend object. No compatibility parser or parallel provider route remains.
@@ -598,6 +598,12 @@ pause does not release RAM. Suspension captures and verifies a full snapshot,
 stops the exact source, and removes its writable compute closure only after the
 artifact is durably identified. Explicit network policy applies on create and
 restore. Do not inherit undeclared host resources.
+The native SDK owns a dedicated ext4 disk mounted at `/environment`, separately
+bounded by `environment_disk_mib` alongside `root_disk_mib`. Workspace, staging
+and outputs must share that filesystem; do not weaken cross-device or link
+checks to accommodate the layered root. Creation uses `/` until bootstrap creates
+the workspace. Existing full snapshots and sandbox cleanup own the disk, with
+no external mount or separate storage lifecycle.
 
 Suspend only after at least one Turn is terminal, no queued/in-progress/waiting
 root or subagent Turn, pending input/file operation or initialization remains,
@@ -1335,6 +1341,87 @@ package with a fresh database, extracted binaries, loaded image and real public
 workflow. Keep model/operator credentials external and Provider ownership stable
 across upgrades. This is the same managed Runtime, not user-managed enrollment.
 
+#### Matched Core and console distribution
+
+The installer milestone packages Core and the unchanged Web console together,
+with independent `--core-only` and `--web-only` modes. `site/` is the public static
+landing, separate from `apps/web`; it must not create an onboarding prerequisite,
+call a model, or claim complete protocol compatibility. Operator installation,
+optional API examples and service diagnostics live in `docs/getting-started/`.
+
+`make build-core-distribution` builds from clean committed source and reuses the
+existing API, Runtime, SDK, helper and Web builders. Artifacts record source and
+immutable image identities, the actual Runtime manifest digest, checksums and
+microsandbox runtime/firmware hashes and executable native payloads. Release generation is not publication or
+qualification. A release must be tested from fresh extraction with real models;
+no synthetic result may substitute for native execution acceptance.
+
+The distribution build sets umask 022 for non-root-readable payloads; installation
+credentials and state retain their explicit private permissions.
+
+The first installer targets a trusted Linux amd64 Docker host. It installs a
+private dedicated PostgreSQL service and separate Core and console services in
+Compose by default, with zero execution nodes. The default requires neither KVM
+nor systemd user services, imports no Runtime image, mounts neither the Docker
+socket nor host devices into Core, and generates no managed Provider configuration.
+Local sandbox placement is opt-in: `--sandbox-provider true --provider microsandbox`
+or `--sandbox-provider true --provider docker`. Enabling the option without naming
+a provider selects microsandbox; `--provider` without enabling the option is an
+error. Web-only mode cannot enable a sandbox provider. Core-only mode retains the
+same opt-in rule. Missing KVM fails when microsandbox is selected without changing
+that choice.
+The distribution supplies native Core/helper binaries and pinned msb runtime and
+firmware. For microsandbox, Core is a native systemd user service with direct
+`ExecStart` and `KillMode=process`: its restart must preserve the Provider's resident
+microVM/helper processes. Never package those processes inside Core's container
+PID namespace, kill their process group on Core stop, or add recovery mechanisms to
+compensate for that packaging. User KVM access, the Linux runtime libraries and
+linger are prerequisites only for the microsandbox option. With the Docker sandbox
+option, Core runs in Compose with the canonical Docker socket. PostgreSQL/Web use
+Compose in either case; native Core
+and its Web proxy use loopback, with a private PostgreSQL port. This packaging
+choice does not change either Provider's execution contract.
+The basic distroless API image and binary builds remain independent artifacts.
+
+One Runtime image contains the existing daemon, shared helpers and three native
+harness packages. Their differences remain in the adapters. Core keeps exclusive
+ownership of Session allocation, initialization, cancellation, snapshots and
+cleanup. When a sandbox provider is enabled, the installer imports its Runtime
+image and prepares running conditions; it never creates an execution Session or
+supplies a model credential. Applications use the
+existing write-only model execution extension, with the installation's persistent
+credential encryption key. Provider identity/backend namespace and native history
+must not change on a repeated install.
+
+`services/core-console` serves the existing production Web build and forwards only
+public `/v1` requests to one configured Core. It uses the standard Go reverse
+proxy with streaming/cancellation, a separate operator password, fixed origin and
+cross-site checks. Only the server reads the Core bearer. It does not implement
+product identity, resource semantics, Runtime discovery or an execution loop.
+The console has neither KVM nor Docker authority; its static root contains no
+secrets. Installation exposes only loopback API/console ports. Remote exposure
+requires an operator-configured HTTPS/access boundary. Web-only mode can connect
+to a loopback existing Core on the same Linux host or a remote HTTPS Core.
+
+Installation state and secrets live in a private directory under `~/.parsar/` by
+default. No credential enters build arguments, image layers, browser bundles or
+diagnostic output. Compose configuration is confidential. The generated database,
+caller/tenant/provider identities and encryption key survive reruns; automatic
+revision replacement and provider migration are outside this initial installer.
+Reruns also refuse enabling or disabling a sandbox provider on an existing
+installation, including adding one to the default zero-node installation.
+Stopping control-plane services does not stop all Provider resources; use Core's
+existing release operations for full cleanup. No native restart promise covers
+host reboot or a lost running microVM. Do not delete data or issue broad
+container/volume pruning as recovery.
+
+`make check-distribution` covers the production proxy, installation rules and
+release metadata. Real bundle validation covers default/provider selection,
+component modes, existing Web connection, public native execution and restart
+retention. Diagnostics report observed service health, not fabricated model or
+complete environment readiness. Runtime observations are Core-owned; do not add
+a duplicate monitoring/lifecycle framework to installation or the public landing.
+
 #### Current implementation
 
 The constraints below describe existing code, not requirements to preserve legacy

Makefile

@@ -8,7 +8,7 @@ SWAG_VERSION ?= v1.16.4
 help:
 	@printf '%s\n' 'make build-agents-api  Build standalone Core commands' 'make build-daemon      Build the execution daemon' 'make check             Run Core, persistence and runtime checks' 'See README.md for runtime prerequisites and deployment.'
 
-check: check-database check-sqlc check-go check-microsandbox-provider check-agents-api check-claude-sdk check-web check-mcode-harness check-agents-executor
+check: check-distribution check-database check-sqlc check-go check-microsandbox-provider check-agents-api check-claude-sdk check-web check-mcode-harness check-agents-executor
 	@printf 'Parsar Core checks passed.\n'
 
 check-database:
@@ -111,3 +111,14 @@ check-microsandbox-provider:
 	else \
 	    printf 'Skipping the Linux-only microsandbox SDK helper tests; the full Linux gate is required before release.\n'; \
 	fi
+
+.PHONY: check-distribution build-core-distribution
+check-distribution:
+	go test ./services/core-console -count=1
+	PYTHONDONTWRITEBYTECODE=1 python3 -m unittest discover -s deploy/install -p 'test_*.py'
+	PYTHONDONTWRITEBYTECODE=1 python3 scripts/core-distribution-manifest.test.py
+	bash -n deploy/install/install.sh scripts/build-core-console.sh scripts/build-core-distribution.sh
+	./scripts/build-core-console.sh
+
+build-core-distribution:
+	./scripts/build-core-distribution.sh

README.md

@@ -1,61 +1,72 @@
 # Parsar Core
 
-Standalone Agent API Core and its execution runtimes, copied from
-[Parsar](https://github.com/MiniMax-AI-Dev/parsar) at
-[`72ab4d37`](https://github.com/MiniMax-AI-Dev/parsar/commit/72ab4d37d49245f15b63d34f5741780e540bcec0).
-The source repository retains both its product and its existing Core copy.
-
-This repository contains the API service, PostgreSQL migrations, pinned public
-protocol, execution daemon, the Docker provider, native Harness adapters,
-runtime image builders, Go and TypeScript client libraries, the standalone Core
-Web console, tests and operator documentation. It does not contain the Parsar
-product application, product backend, product database, business CLI or product
-deployment stack.
-
-V1 user-managed deployments colocate our daemon, selected harness, tools and
-`/workspace`. Core manages Docker only; users provision, renew and destroy E2B
-through the official SDK. The returned `remote_url` uses our private daemon
-transport, not stock `exec-server`. See the
-[Runtime enrollment guide](services/agents-api/README.md#user-managed-runtime-enrollment)
-for harness enablement and the [qualification record](contracts/agents-api/user-managed-runtime-v1.md)
-for tested deployments and remaining limits.
+**Open-source Agents API infrastructure, with your choice of native harness.**
+
+Run Codex, Claude Code and MiniMax Code behind one execution API. Parsar Core
+owns Sessions, environments, files, credentials and execution history; each
+native harness keeps its own model and tool loop. Core runs independently of the
+Parsar product.
+
+Core and its Web console ship together. The default installation runs Core, Web
+and PostgreSQL with zero execution nodes. A local sandbox provider is optional:
+enable microsandbox or Docker explicitly when installing. With a provider enabled,
+Core creates each required sandbox from the colocated Runtime image. Model
+credentials are supplied through the existing write-only API extension.
 
 ## Start here
 
-- [API setup, authentication and execution](services/agents-api/README.md)
-- [Standalone containers](services/agents-api/CONTAINER.md)
-- [Docker Runtime](services/agents-api/deploy/codex/README.md)
-- [Protocol coverage and known gaps](contracts/agents-api/README.md)
-- [Harness selection](contracts/agents-api/harness-selection.md)
-- [Core Web overview](docs/web/README.md)
-- [Core Web 中文说明](docs/web/README.zh-CN.md)
-- [Connect Core Web to Core](docs/web/core-connection.md)
-- [Contributor rules](CONTRIBUTING.md)
-- [Copy provenance and validation](provenance/README.md)
+- [Install Core and Web](docs/getting-started/install.md)
+- [Make your first API request](docs/getting-started/quickstart.md)
+- [Service health, data and operations](docs/getting-started/operations.md)
+- [Protocol coverage and native differences](contracts/agents-api/README.md)
+- [Add or select a harness](contracts/agents-api/harness-selection.md)
+- [Public landing page source](site/index.html)
+
+After verifying and extracting a matching Linux amd64 distribution:
+
+```sh
+./install.sh                    # Core + Web + PostgreSQL, no sandbox provider
+./install.sh --core-only        # Core + PostgreSQL, no sandbox provider
+./install.sh --sandbox-provider true --provider microsandbox
+./install.sh --sandbox-provider true --provider docker
+```
+
+Web-only installation connects the unchanged console to an existing Core; see the
+installation guide for its URL and private credential-file options. Installation
+never creates a sample Session or calls a model. API examples are optional.
+
+The protocol baseline is `openai-python` 3.13.0 and `agents=v1`. Harness selection,
+model execution configuration and our daemon transport are documented differences.
+A passing workflow does not establish complete OpenAI Agents API compatibility.
+
+## Develop and build
+
+The repository includes the API, its independent PostgreSQL migrations, daemon,
+Runtime/provider adapters, clients, Web console and distribution tools. It has no
+Parsar product service, product database or business-user dependency.
 
 ```sh
 make build-agents-api
 make build-daemon
 pnpm dev:web
 ```
 
-These builds require the Go version pinned in `go.mod`. Output goes under
-`~/.parsar/build/`; no product checkout, frontend or product database is needed.
-Provision a dedicated Core PostgreSQL database and caller credentials using the
-operator guide before starting the service. Native execution also needs the
-appropriate Runtime image and provider configuration.
-
-Core Web lives in `apps/web` and talks only to the public `/v1/agents/**`
-HTTP/SSE contract through the TypeScript implementation in
-`packages/agents-client`. The Go client remains in
-`packages/agents-client/v1`; both clients live next to the contract they consume
-without coupling browser state to Core execution internals.
-
-The copied Go module/import paths, executable names and `PARSAR_*` environment
-variables intentionally retain their existing names. They resolve to source in
-this checkout, not a dependency on the Parsar product repository. This extraction
-does not rename protocols or change execution behavior. Third-party native
-sources and packages remain pinned dependencies, not vendored binaries.
+Use the toolchain pinned in `go.mod`, Node 22 and pnpm 10.30.3. Build output goes
+under `~/.parsar/build/`. For advanced deployment, see the
+[service guide](services/agents-api/README.md),
+[Docker Runtime](services/agents-api/deploy/codex/README.md),
+[microsandbox provider](services/agents-api/deploy/microsandbox/README.md), and
+[Web development guide](docs/web/README.md).
+
+Core-managed and user-managed environments reuse the colocated daemon, native
+harness, tools and workspace. E2B uses caller-managed provisioning through the
+official SDK; the returned `remote_url` connects our daemon, not `exec-server`.
+See the [Runtime enrollment guide](services/agents-api/README.md#user-managed-runtime-enrollment).
+
+Read [CONTRIBUTING.md](CONTRIBUTING.md) before developing. Historical source-copy
+provenance is retained in [provenance/README.md](provenance/README.md). Existing Go
+import paths resolve inside this repository and do not require the product repo.
+Third-party native packages remain pinned build dependencies.
 
 ## Validate
 

deploy/distribution/Dockerfile

@@ -0,0 +1,15 @@
+# Context contains matched Core binaries and the verified microsandbox v0.7.2 release.
+# The helper embeds its pinned SDK FFI; unlike the basic static image, this image
+# supplies the glibc runtime needed to load that library.
+FROM debian:bookworm-slim@sha256:a0982977ea1cf754c15281f48a7d5957cd14039a2a4f2aca9f23d74d226003d0
+
+RUN apt-get update && apt-get install -y --no-install-recommends ca-certificates libgcc-s1 \
+    && rm -rf /var/lib/apt/lists/*
+
+COPY --chmod=0555 bin/agents-api bin/agents-api-migrate bin/agents-api-device bin/agents-api-environment-key bin/agents-api-microsandbox-provider /usr/local/bin/
+COPY --chmod=0555 microsandbox/msb microsandbox/libkrunfw.so.5.6.1 /opt/microsandbox/
+
+ENV AGENTS_API_ADDR=:8091
+EXPOSE 8091
+USER 65532:65532
+CMD ["/usr/local/bin/agents-api"]

deploy/distribution/Runtime.Dockerfile

@@ -0,0 +1,29 @@
+# Each input is an immutable Linux amd64 image built from the same Core revision.
+# Reuse the native packages and isolation configuration from existing profiles.
+ARG CODEX_IMAGE
+ARG CLAUDE_IMAGE
+ARG MCODE_IMAGE
+FROM ${CODEX_IMAGE} AS codex
+FROM ${CLAUDE_IMAGE} AS claude
+FROM ${MCODE_IMAGE}
+
+# Keep the shared daemon, helpers and prebuilt tool-system seed from this base.
+# Native harness packages remain outside the tool-system seed and workspace.
+COPY --from=codex /usr/local/bin/codex /usr/local/bin/codex
+COPY --from=codex /usr/local/codex-resources /usr/local/codex-resources
+COPY --from=codex /etc/codex /etc/codex
+COPY --from=claude /opt/claude-sdk /opt/claude-sdk
+COPY --from=claude /usr/local/bin/agents-api-claude-shell-prefix /usr/local/bin/agents-api-claude-shell-prefix
+
+ENV PARSAR_CODEX_BIN=/usr/local/bin/codex \
+    PARSAR_CODEX_PERMISSION_PROFILE=managed-workspace \
+    PARSAR_CLAUDE_SDK_NODE=/usr/local/bin/node \
+    PARSAR_CLAUDE_SDK_ENTRYPOINT=/opt/claude-sdk/dist/main.js \
+    PARSAR_CLAUDE_SDK_WORKSPACE=managed
+
+USER 1000:1000
+RUN test "$(codex --version)" = "codex-cli 0.153.4" \
+    && test -r /etc/codex/requirements.toml \
+    && node /opt/claude-sdk/dist/runtime_check.js /opt/claude-sdk/dist/main.js \
+    && node /opt/mcode-harness/check.mjs \
+    && /opt/mcode-harness/native/cli.js --version