Skip to content

feat(cloud-agent-next): introduce provider-neutral agent sandbox structure#4552

Open
eshurakov wants to merge 3 commits into
mainfrom
peridot-split
Open

feat(cloud-agent-next): introduce provider-neutral agent sandbox structure#4552
eshurakov wants to merge 3 commits into
mainfrom
peridot-split

Conversation

@eshurakov

Copy link
Copy Markdown
Contributor

Summary

Add the structural seams for supporting multiple sandbox providers in cloud-agent-next, with no change to current runtime behavior. Cloudflare remains the only provider today; these seams replace hard-coded provider assumptions with a typed capability matrix so additional providers can be added behind a single boundary.

  • sandboxProvider identity in session metadata (defaulting to cloudflare), backed by a static PROVIDER_CAPABILITIES matrix. Metadata validation now gates capabilities (e.g. devcontainer) via that table instead of provider name checks.
  • A provider factory plus an AgentSandboxLifecycle reconciliation seam for settling interrupted runtime creation and driving deletion to a terminal state. Cloudflare returns no-ops since its runtimes are locally addressed.
  • A typed AgentSandboxUnavailableError taxonomy, surfaced as a permanent SANDBOX_CAPABILITY_UNAVAILABLE delivery failure, with terminal capability-unavailable outcomes (e.g. terminal access).
  • Transport-only WrapperClient construction for providers that expose no public wrapper port.
  • Provider selection at session registration via selectSandboxForNewSession.
  • A durable session deletion intent (session_deletion_intent) that fences further runtime use, survives payload purge, and supports deferred provider-side deletion reconciled via alarms.

Verification

  • No manual testing performed. This is a structural change only — Cloudflare stays the sole provider and runtime behavior is unchanged, so there is no new user-facing path to exercise by hand. New and adjusted behavior is protected by added unit and integration tests.

Visual Changes

N/A

Reviewer Notes

  • No runtime/behavioral change for the existing Cloudflare provider; all lifecycle seams are no-ops for it.
  • Local automated checks all green: format:check, lint, typecheck, unit tests (98 files / 2213 passed), integration tests (24 files / 214 passed).
  • Suggested focus areas: the durable deletion-intent fencing in persistence/CloudAgentSession.ts, and the SANDBOX_CAPABILITY_UNAVAILABLE permanent-failure surfacing across execution/errors.ts + execution/orchestrator.ts.

…cture

Add the structural seams for supporting multiple sandbox providers:
a sandboxProvider identity in session metadata with a static capability
matrix, a provider factory and lifecycle-reconciliation seam, a typed
AgentSandboxUnavailableError taxonomy surfaced as a permanent
SANDBOX_CAPABILITY_UNAVAILABLE delivery failure, terminal
capability-unavailable outcomes, transport-only WrapperClient
construction for providers without a public wrapper port, provider
selection at session registration, and a durable session deletion
intent that fences runtime use and supports deferred provider-side
deletion. Cloudflare remains the only provider.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Comment thread services/cloud-agent-next/src/persistence/CloudAgentSession.ts Outdated
@kilo-code-bot

kilo-code-bot Bot commented Jul 15, 2026

Copy link
Copy Markdown
Contributor

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Executive Summary

The incremental changes are limited to local E2E test-harness documentation and timeout tuning (DEBUG.md, README.md, AGENTS.md, lifecycle.ts, client.ts, smoke.ts) with no application/runtime code affected; the previously flagged deferred-deletion purge issue in CloudAgentSession.ts remains fixed and unaffected by this update.

Files Reviewed (6 files)
  • services/cloud-agent-next/AGENTS.md
  • services/cloud-agent-next/DEBUG.md
  • services/cloud-agent-next/test/e2e/README.md
  • services/cloud-agent-next/test/e2e/client.ts
  • services/cloud-agent-next/test/e2e/lifecycle.ts
  • services/cloud-agent-next/test/e2e/smoke.ts
Previous Review Summaries (2 snapshots, latest commit b68565d)

Current summary above is authoritative. Previous snapshots are kept for context only.

Previous review (commit b68565d)

Status: No Issues Found | Recommendation: Merge

Executive Summary

The deferred-deletion purge fix correctly retains provider entry keys during purgeDeletedSessionPayload(), resolving the previously flagged issue, and is backed by a new integration test.

Files Reviewed (2 files)
  • services/cloud-agent-next/src/persistence/CloudAgentSession.ts
  • services/cloud-agent-next/test/integration/session/deletion-lifecycle.test.ts

Previous review (commit 18b98cc)

Status: 1 Issue Found | Recommendation: Address before merge

Executive Summary

The deferred-deletion path in CloudAgentSession.initiateSessionDeletion persists provider deletion-plan entries and then immediately deletes them via purgeDeletedSessionPayload(), since that method's retained-key set is never extended to cover them.

Overview

Severity Count
CRITICAL 0
WARNING 1
SUGGESTION 0
Issue Details (click to expand)

WARNING

File Line Issue
services/cloud-agent-next/src/persistence/CloudAgentSession.ts 1962 purgeDeletedSessionPayload() deletes the just-persisted deletionPlan.entries because retainedKeys only keeps DELETION_INTENT_KEY; currently dead code since Cloudflare's planDeletion never returns deferred, but will silently destroy a future provider's deferred-deletion state.
Files Reviewed (36 files)
  • services/cloud-agent-next/.dev.vars.example
  • services/cloud-agent-next/src/agent-sandbox/agent-sandbox-contract.test.ts
  • services/cloud-agent-next/src/agent-sandbox/capabilities.ts
  • services/cloud-agent-next/src/agent-sandbox/factory.test.ts
  • services/cloud-agent-next/src/agent-sandbox/factory.ts
  • services/cloud-agent-next/src/agent-sandbox/protocol.ts
  • services/cloud-agent-next/src/execution/errors.ts
  • services/cloud-agent-next/src/execution/orchestrator.test.ts
  • services/cloud-agent-next/src/execution/orchestrator.ts
  • services/cloud-agent-next/src/execution/types.ts
  • services/cloud-agent-next/src/kilo/wrapper-client.test.ts
  • services/cloud-agent-next/src/kilo/wrapper-client.ts
  • services/cloud-agent-next/src/persistence/CloudAgentSession.ts - 1 issue
  • services/cloud-agent-next/src/persistence/session-metadata.test.ts
  • services/cloud-agent-next/src/persistence/session-metadata.ts
  • services/cloud-agent-next/src/persistence/types.ts
  • services/cloud-agent-next/src/router.test.ts
  • services/cloud-agent-next/src/router/handlers/session-management.ts
  • services/cloud-agent-next/src/router/handlers/session-questions.ts
  • services/cloud-agent-next/src/sandbox-id.test.ts
  • services/cloud-agent-next/src/sandbox-id.ts
  • services/cloud-agent-next/src/server.test.ts
  • services/cloud-agent-next/src/session-prepare.test.ts
  • services/cloud-agent-next/src/session-service.test.ts
  • services/cloud-agent-next/src/session/agent-runtime.test.ts
  • services/cloud-agent-next/src/session/agent-runtime.ts
  • services/cloud-agent-next/src/session/pending-messages.ts
  • services/cloud-agent-next/src/session/session-message-queue.test.ts
  • services/cloud-agent-next/src/session/session-message-queue.ts
  • services/cloud-agent-next/src/session/session-registration.ts
  • services/cloud-agent-next/src/terminal/access.test.ts
  • services/cloud-agent-next/src/terminal/access.ts
  • services/cloud-agent-next/src/types.ts
  • services/cloud-agent-next/test/integration/session/deletion-lifecycle.test.ts
  • services/cloud-agent-next/test/integration/session/pending-messages.test.ts
  • services/cloud-agent-next/test/integration/session/start-execution-v2.test.ts
  • services/cloud-agent-next/test/unit/execution/orchestrator.test.ts

Fix these issues in Kilo Cloud


Reviewed by claude-sonnet-5 · Input: 36 · Output: 5.9K · Cached: 980.8K

Review guidance: REVIEW.md from base branch main

…ugh payload purge

purgeDeletedSessionPayload() only retained the deletion-intent fence, so the
deferred-deletion branch deleted the provider entries it had just persisted.
Pass the plan's entry keys as additional retained keys and cover the path
with an integration test.
Increase per-scenario timeout from 90s to 120s to give margin over the
3x30s wrapper startup path under Docker contention. Add pre-run cleanup
of stale sandbox containers to prevent cross-run accumulation that
degrades Docker Desktop performance.

Document three failure modes discovered during local validation:
- Non-zero portOffset sessions require WORKER_URL/FAKE_LLM_URL overrides
- git-token-service-dev missing from dev-registry (stale wrangler process)
- @cloudflare/containers 503 container control connection under Docker load
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants