[eshurakov]

Problem

Repository snapshots exist to avoid a cold clone and install on every start, but since #7238 (a60fcc5d1) a route with any setup command was made snapshot-ineligible (has_setup_commands) - so exactly the heavy-setup routes got no snapshot.

The exclusion was correct for the old key, not an accident: capture runs after setup, and the key hashed only the user and the repository URL, so setup output would be published under a key that routes with a different setup would also resolve to and adopt.

Change

• Fold a digest of the setup commands into the snapshot key (computeRepoKey) instead of refusing a key. A snapshot is now reused only by a route whose setup matches; a different setup for the same repository gets its own key.
• Absent and empty setup commands produce the same legacy key, so existing no-setup snapshots keep working.
• Drop the has_setup_commands eligibility gate and its reason.
• Update docs/control-plane.md (Key and Capture sections).
• Update unit and integration tests.

The setup commands are SHA-256 hashed before joining the HMAC message, so a secret-bearing command never enters it.

Behavior

• A route with setup commands now gets a key, launches from its snapshot when one exists, and asks the wrapper to capture after setup.
• Two routes on the same user/repo with different setup commands get different keys and never share a snapshot.

Verification

• pnpm --filter cloud-agent-next run test - 6249 passed
• pnpm --filter cloud-agent-next run test:integration - 680 passed
• pnpm --filter cloud-agent-next run lint - 0 warnings/errors
• pnpm --filter cloud-agent-next run typecheck

Setup-bearing routes start capturing from the first session after deploy; no-setup routes are unaffected.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Executive Summary

The PR correctly folds a SHA-256 digest of setup commands into the repository snapshot key, removing the setup-command eligibility gate; the no-setup key path and the session.prepare capture wiring remain intact, and I found no defects in the changed lines.

Files Reviewed (5 files)

• services/cloud-agent-next/docs/control-plane.md - documentation updated to match the new key identity; verified consistent with the implementation (setup always re-runs on clone/adopt in wrapper/src/control-plane/prepare.ts, and capture occurs after setup).
• services/cloud-agent-next/src/control-plane/sandbox/repo-key.ts - has_setup_commands gate and reason removed; RepoKeyInput.setupCommands added; key message includes the setup digest only when setup commands are present, so absent/empty reproduce the legacy user+repo key. Verified the raw commands are hashed (never placed in the HMAC message) before use.
• services/cloud-agent-next/src/control-plane/sandbox/repo-key.test.ts - removed the obsolete ineligibility test; new test covers setup-folding and legacy no-setup key stability.
• services/cloud-agent-next/src/control-plane/sandbox/sandbox-do.ts - eligibility call no longer passes setup commands; computeRepoKey receives spec.setupCommands, matching the commands the wrapper executes.
• services/cloud-agent-next/test/integration/sandbox-control-v2-repo-snapshots.test.ts - setup routes now assert a key and capture: true; added a distinct-setup different-key case.

---

_{Reviewed by deepseek-v4.1-flash · Input: 110.8K · Output: 21.1K · Cached: 1.9M}

_{Review guidance: REVIEW.md from base branch main}