Files
DottaandPaperclip 60c7c9cd1a fix(runner-e2e): pass verified lock digest to Daytona image build (#13876)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - Product E2E campaigns test the native runner in local and Daytona
environments.
> - Each campaign resolves one target lockfile and verifies its
downloaded artifact.
> - The Daytona image job did not pass that artifact digest to Docker.
> - Docker used an older default digest and stopped before any selected
task ran.
> - This pull request passes and validates the campaign digest at the
image build boundary.
> - The image keeps its checksum check and frozen package installation.

## Linked Issues or Issue Description

**What happened?**

The merged-master [qualification
campaign](https://github.com/paperclipai/paperclip/actions/runs/35863582409)
stopped in the Daytona image build. The resolved target lock digest was
`e0c928a494f90ddad3c00791e83f09315ee8c82df2a0418a809dcf93649a8ab3`.
Docker used its default digest,
`57b298aceebc48bb94ea0593347348256475da7b2fddb77025d9e57cc8759420`. The
checksum check rejected the mismatch. All 12 selected model cells were
skipped. This follows the image provenance work in #13814.

**Expected behavior**

The image build must check the same lockfile artifact that the campaign
restored and verified. A changed lockfile must still fail the checksum
check.

**Steps to reproduce**

1. Start a Product E2E campaign with a Daytona cell on master
`7944ed3d976d1a7cc26a2d0cee51f227f3542084`.
2. Resolve a target lockfile whose digest differs from the Dockerfile
default.
3. Observe the provider-pack image stage reject the lockfile before
model execution.

**Paperclip version or commit**

`7944ed3d976d1a7cc26a2d0cee51f227f3542084`.

**Deployment mode**

GitHub Actions Product E2E campaign with a Daytona image build.

**Install method**

Built from source with the campaign lockfile artifact.

**Agent adapter(s) involved**

Native Codex and ACPX Claude cells were selected. No model cell ran in
this failed campaign.

**Database mode**

Not involved. The failure occurs during image creation.

**Access context**

The authorized default-branch paid workflow. The build receives no
provider credentials.

## What Changed

- Read the image checksum from the existing target-lock job output.
- Require a 64-character lowercase hexadecimal digest before image
inspection or build.
- Pass the digest as the existing Docker build argument.
- Add regression checks and document the campaign checksum handoff.

## Verification

- The Daytona image regression fails with the original workflow and
passes with the fix.
- All six Daytona image contract tests pass.
- All 450 Product E2E unit tests pass.
- Product E2E typecheck passes.
- Actionlint passes for the changed workflow.
- A context-shaped resolution probe preserves the downloaded lockfile
bytes and digest.
- All latest-head CI checks passed on
`67d41fd9439b2a9a809ddb05765f8617585072c5`
([run](https://github.com/paperclipai/paperclip/actions/runs/35865739359)).
- Greptile gave 5/5 on this head; its test-scoping comment is addressed
and resolved.
- A hosted Daytona image rebuild and the three remote qualification
cells remain pending after merge.

## Risks

The campaign digest comes from the existing trusted target-lock job. The
restored artifact checks, Docker checksum check, frozen install, content
identity, image signing, and verification remain in place. The
standalone Docker default remains available. This change does not alter
task behavior, prompts, credentials, or dependency versions.

## Model Used

OpenAI `gpt-6-astra` through Codex performed diagnosis and review with
code execution tools. OpenAI `gpt-5.6-luna` assisted with investigation,
implementation, and verification. Context window limits are not exposed
in this session.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

---------

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-09-23 08:45:52 -05:00
..

Paperclip Daytona runner image

This image is the Paperclip Cloud fleet sandbox image plus a source-built paperclip-runnerd and immutable provider pack. The pack contains Node 24.11, OpenCode 1.18.32, the compiled OpenCode proxy, ACPX 0.13.1 sidecar, qualified ACP agents, and the production lockfile. Its manifest digests each executable bridge and binds the pack to the runner source revision, avoiding artifact upload and npm installation on every fresh lease.

The fleet pins are intentionally copied from paperclip-cloud/fleet-sandbox-image/Dockerfile. Update both definitions together until the fleet base is published as a stable image that this Dockerfile can extend directly.

Harness versions

The September 22, 2026 refresh pins Codex 0.156.0, Claude Agent SDK 0.3.280 (Claude Code 2.1.280), and OpenCode 1.18.32 in the shared provider pack. Claude Code 2.1.280 is the minimum for Opus 5.5; it also supports Fable 5.1. Codex uses the current GPT-6 Sol and Luna model IDs. Grok CLI 1.0.41 supports the current Grok 4.7 model family.

Keep the patched ACP bridge versions separate from their CLI runtime pins. Their executable digests do not change when only the runtime dependency changes. Refresh the runtime executable digests from integrity-verified npm release archives for every supported platform, and keep the native runner, provider manifest, and remote controller version checks aligned.

Build and verify

Run pnpm --filter @paperclipai/paperclip-runner test:opencode:qualification after installing dependencies to exercise the actual pinned OpenCode executable. It checks health/version, session creation and retrieval, SSE messages, an async prompt, and session deletion against a loopback mock provider. It uses an isolated home, starts no paid model request, and retires its process group. Set PAPERCLIP_TEST_OPENCODE_BINARY to the materialized Linux executable when qualifying an assembled provider pack.

The fleet image is currently amd64-only because the pinned Cursor and GitHub CLI checksums cover amd64.

content_id="$(pnpm --silent test:e2e:runner:image-id)"
docker buildx build \
  --platform linux/amd64 \
  --build-arg PAPERCLIP_RUNNER_CONTENT_ID="${content_id}" \
  --build-arg PAPERCLIP_RUNNER_SOURCE_REVISION="$(git rev-parse HEAD)" \
  --tag "paperclip-daytona-runner:e2e-content-${content_id}" \
  --load \
  --file docker/daytona-runner/Dockerfile \
  .

docker run --rm --platform linux/amd64 \
  --entrypoint paperclip-runnerd \
  "paperclip-daytona-runner:e2e-content-${content_id}" \
  --build-metadata

The metadata must advertise dial_ws_loopback, dial_wss, and listen_ws. The explicit entrypoint is needed only for this local probe because Daytona's base image uses its own long-running sandbox entrypoint.

test:e2e:runner:image-id hashes the audited Docker build dependency closure, target platform, the immutable Dockerfile syntax-frontend digest, and every immutable FROM reference. It fails before the paid workflow can build when the frontend or a base is not pinned to a sha256 digest. When updating the syntax version, resolve and review its registry digest and update both values in the first Dockerfile line. Git commits that do not change those inputs reuse the same content tag.

PAPERCLIP_RUNNER_SOURCE_REVISION remains the full Git SHA that built the first published copy and is retained as provenance rather than cache identity.

Use in Paperclip

Publish the image to a registry Daytona can pull, or use the environment editor's Configure image flow to produce a Daytona snapshot. Set the environment image to that immutable tag or snapshot. Paperclip probes the sandbox user's PATH for paperclip-runnerd and codex and checks /opt/paperclip-runner/provider-pack for OpenCode and ACPX. It uses the pack only when its complete manifest matches the controller's build-owned pack; otherwise it stages the pack configured by PAPERCLIP_RUNNER_REMOTE_PROVIDER_PACK_PATH. Remote OpenCode and ACPX never fall back to host-local processes.

Do not promote paperclip-runner-e2e-20260826-v2 for OpenCode or ACPX. Build a new immutable image or snapshot from a clean committed revision and pass that full Git SHA as PAPERCLIP_RUNNER_SOURCE_REVISION.

Do not bake provider credentials, Paperclip bootstrap tickets, or Daytona preview tokens into this image. They remain per-run secret material.

Provider CLI updates are manifest-only changes: repository CI owns the root lockfile. The image build resolves the complete workspace manifest graph before its frozen install, matching CI when a source commit precedes the lockfile bot. The complete resolved lockfile must match PAPERCLIP_RUNNER_LOCK_SHA256 before package installation or lifecycle execution. Review and refresh that digest with source dependency changes; registry-time resolution drift fails closed. The Product E2E workflow resolves one lockfile before the image build. It verifies the downloaded artifact, then passes that artifact's SHA-256 as the PAPERCLIP_RUNNER_LOCK_SHA256 build argument. The Dockerfile checks the resolved lock against this value before installation. The fixed Dockerfile default is for standalone builds; it must not replace a campaign's verified lock digest. Keep one latest stable CLI installation per provider; refresh exact runtime versions and qualification digests together, never install a private older copy or download dependencies when a task starts.