Skip to content

feat(agents): publish immutable payloads for remote gateways #2500

Description

@drew

Problem Statement

The manifest-driven agent launcher always stages the rendered prompt, skills,
subagents, and shared runtime into a local Dockerfile context. This works for
local gateways, but remote gateways reject the resulting local --from source:

local Dockerfile sources are only supported for local gateways

As a result, repository-owned agents such as gator cannot launch on remote
gateways without an operator manually reproducing the payload staging, building
an image, pushing it to a registry, and substituting the registry reference.

Proposed Design

Add an agent-agnostic OCI publisher and integrate it with the generic launcher:

  • Add scripts/agents/publish.sh, which accepts any Dockerfile or context,
    publishes it to an OCI repository, and prints a digest-pinned reference.
  • Add --publish-to REPOSITORY and --platform PLATFORM to
    scripts/agents/run.sh, with matching environment overrides for automation.
  • Continue staging the immutable payload exactly as the local launch path does,
    then pass the staged Dockerfile to the standalone publisher.
  • Generate a collision-resistant tag for the publication, but read the
    authoritative pushed digest from BuildKit's metadata file.
  • Pass REPOSITORY@sha256:... to openshell sandbox create so the launch is
    immutable and cannot race a mutable tag.
  • Publish before changing gateway settings or providers, leaving the gateway
    untouched when the build or push fails.
  • Preserve existing behavior when --publish-to is absent.
  • When a local Dockerfile is used with a remote gateway without publication,
    emit actionable guidance that points to --publish-to.

The publisher does not know about gator, agent manifests, prompts, providers, or
gateway state. Other agent launchers and CI workflows can reuse it directly.
Registry authentication remains external to the publisher. Operators configure
the appropriate Docker credential helper for Artifact Registry, ECR, GHCR, or
another OCI registry before launch.

Example:

./scripts/agents/run.sh \
  --agent gator \
  --gateway drew-sandbox \
  --publish-to us-central1-docker.pkg.dev/example/openshell/gator \
  --platform linux/amd64 \
  --name gator-pr-2253-supervised \
  --watch \
  --background \
  "Review and monitor PR #2253 through the gator-gate workflow."

The launcher should warn operators that the published image contains the
rendered agent payload, including the operator prompt, and recommend a private
registry with an appropriate retention policy.

Alternatives Considered

  • Teach the CLI to upload local Docker build contexts to remote gateways.
    This requires a remote build service and a much larger API/security design.
  • Upload the payload into /sandbox. The agent could modify its own prompt,
    skills, and runtime, breaking the current immutable agent-guts boundary.
  • Add GCP Artifact Registry logic to gator. This solves one environment but
    makes the generic launcher provider-specific.
  • Publish one static gator image in CI. This does not preserve per-launch
    rendered prompts and prevents arbitrary repository agents from using the same
    mechanism.

Agent Investigation

  • Reproduced with drew-sandbox and PR feat(examples): run Jupyter notebooks in an OpenShell sandbox #2253.
  • Confirmed GitHub auth, Codex auth, gateway connectivity, and provider refresh
    were healthy.
  • Confirmed no sandbox was created when the launcher passed the staged local
    Dockerfile to the remote gateway.
  • Built the same staged payload for linux/amd64, pushed it to a private GCP
    Artifact Registry, and launched the remote sandbox by registry reference.
  • Confirmed the remote gateway accepted the image and created
    gator-pr-2253-supervised.
  • Relevant implementation points are prepare_immutable_sandbox_source and
    SANDBOX_CMD in scripts/agents/run.sh.

Acceptance Criteria

  • Existing local agent launches are unchanged.
  • A staged immutable agent payload can be published to any authenticated OCI
    repository.
  • Publishing is reusable without depending on gator.
  • Remote sandbox creation uses the pushed digest, not a mutable tag.
  • Build, push, malformed metadata, and digest-substitution behavior have
    automated coverage.
  • Agent launcher and gator documentation include remote examples and
    security guidance.
  • The launch-openshell-gator skill documents the supported remote path.
  • A supervised gator payload published to GCP Artifact Registry was accepted
    by drew-sandbox and reached Ready as gator-pr-2253-supervised.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions