You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
--fromsource: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:
scripts/agents/publish.sh, which accepts any Dockerfile or context,publishes it to an OCI repository, and prints a digest-pinned reference.
--publish-to REPOSITORYand--platform PLATFORMtoscripts/agents/run.sh, with matching environment overrides for automation.then pass the staged Dockerfile to the standalone publisher.
authoritative pushed digest from BuildKit's metadata file.
REPOSITORY@sha256:...toopenshell sandbox createso the launch isimmutable and cannot race a mutable tag.
untouched when the build or push fails.
--publish-tois absent.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
This requires a remote build service and a much larger API/security design.
/sandbox. The agent could modify its own prompt,skills, and runtime, breaking the current immutable agent-guts boundary.
makes the generic launcher provider-specific.
rendered prompts and prevents arbitrary repository agents from using the same
mechanism.
Agent Investigation
drew-sandboxand PR feat(examples): run Jupyter notebooks in an OpenShell sandbox #2253.were healthy.
Dockerfile to the remote gateway.
linux/amd64, pushed it to a private GCPArtifact Registry, and launched the remote sandbox by registry reference.
gator-pr-2253-supervised.prepare_immutable_sandbox_sourceandSANDBOX_CMDinscripts/agents/run.sh.Acceptance Criteria
repository.
automated coverage.
security guidance.
launch-openshell-gatorskill documents the supported remote path.by
drew-sandboxand reached Ready asgator-pr-2253-supervised.