[eshurakov]

Summary

Deleting a workspace session left its Cloudflare sandbox allocation running until the Durable
Object idle sweep (10 minutes), so a workload that creates and deletes sessions never released its
containers. A manual Cloud Agent E2E tests run hit the e2e Worker's container cap because of this:
512 There is no container instance that can be provided to this Durable Object and 11
Maximum number of running container instances exceeded errors, with exactly 20 containers started.

SandboxControl.forgetSessionReference now stops the allocation when the deleted session was the
sandbox's sole owner:

• session-ingest gains retireWorktreeIfSoleMember. It runs under the same worktree row lock as
  registerCloudAgentWorktree, so a sibling chat either commits first (visible, shared) or loses
  registration after the retirement marker (WORKTREE_DELETING). For a sole member it writes the
  full worktree deletion state through the extracted beginWorktreeDeletionOn, so a later public
  deleteWorktree can still parse the manifest and resume cleanup.
• SandboxControl.forgetSessionReference removes the tombstone, then retires and stops via a shared
  stopFor(reason). It stays a no-op for shared and legacy-shared sandbox ids, when another route
  or reference remains, when an exclusive deletion fence is set, and for creating/unknown
  allocations. Only state.kind === 'stopped' is reported as confirmed.
• SandboxSession.deleteSession forwards the worktree, user and organization metadata; it does not
  decide.

Verification

Manually exercised against the local dev stack (real Worker + Durable Object + sandbox + wrapper),
not only unit tests:

• cold-hot echo:hi completed twice with real fake-LLM dispatches.
• After deleteSession the sandbox container appeared and then disappeared
  (docker ps polled independently), with the product chain
  allocated.healthy → stopping.destroying (reason: session_deleted) → stopped (destroy_confirmed)
  and session_deleted_stop result: 'stopped'. The container lifetime was ~15s, so the 5-minute
  idle sweep is excluded as the cause.

Automated: session-ingest worktree-deletion 43 passed; cloud-agent-next unit 245 passed;
integration (worktree-deletion, sandbox-control, deletion-lifecycle) 369 passed; typecheck and
oxlint clean.

Visual Changes

N/A

Reviewer Notes

• Deployment order matters: deploy session-ingest before cloud-agent-next. If the caller is
  ahead, the missing RPC fails closed (no stop) rather than guessing.
• A session whose worktree still has another member is deliberately not stopped, so
  worktree-multi-chat keeps one container until the idle sweep. Sandbox-wide exclusivity for
  shared (org-/usr-) sandbox ids is out of scope.
• The stop is attempted only for an allocated allocation. A delete that races a sandbox boot can
  still launch; the first heartbeat with an empty route table arms the existing idle sweep.
• retention-expired deletion and the legacy cloud-agent-sandbox.ts path are unchanged.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Executive Summary

The follow-up commit fa267edf28 resolves both prior findings. exactSoleMember now counts only entries with a non-null cloudAgentSessionId, so subagent children no longer block retirement, and retireWorktreeIfSoleMember re-checks the committed manifest before returning exclusive, so a concurrently committed root owner cannot authorize a sandbox stop. No new issues were found in the incremental diff.

Files Reviewed (11 files)

• AGENTS.md
• packages/session-ingest-contracts/src/rpc-contract.ts
• services/cloud-agent-next/src/persistence/SandboxControl.ts
• services/cloud-agent-next/src/sandbox-control/lifecycle.test.ts
• services/cloud-agent-next/src/sandbox-session/SandboxSession.ts
• services/cloud-agent-next/src/sandbox-session/control-rpc.ts
• services/cloud-agent-next/src/telemetry/control-plane-failure-fence.test.ts
• services/cloud-agent-next/test/integration/worktree-deletion.test.ts
• services/session-ingest/src/services/worktree-deletion.test.ts - re-reviewed, prior findings fixed
• services/session-ingest/src/services/worktree-deletion.ts - re-reviewed, prior findings fixed
• services/session-ingest/src/session-ingest-rpc.ts

Previous Review Summary (commit 6480d7a)

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

Previous review (commit 6480d7a)

Status: 2 Issues Found | Recommendation: Address before merge

Executive Summary

The new sole-member retirement can stop a sandbox whose worktree has a concurrently-created sibling session, because the exclusive/shared decision is read without lockRoots and can disagree with the manifest it writes.

Overview

Severity	Count
CRITICAL	0
WARNING	1
SUGGESTION	1

Issue Details (click to expand)

WARNING

File	Line	Issue
services/session-ingest/src/services/worktree-deletion.ts	365	retireWorktreeIfSoleMember decides exclusive from an unlocked discoverMembers read, but the manifest is written by a second locked read; a concurrently created child session can commit in between, so the committed manifest has two members while the caller still stops the sandbox.

SUGGESTION

File	Line	Issue
services/session-ingest/src/services/worktree-deletion.ts	331	exactSoleMember treats null-cloudAgentSessionId child rows as other members, so a root session with subagent children is never retired and the sandbox leak persists for those sessions.

Files Reviewed (11 files)

• AGENTS.md - no issues
• packages/session-ingest-contracts/src/rpc-contract.ts - no issues
• services/cloud-agent-next/src/persistence/SandboxControl.ts - no issues
• services/cloud-agent-next/src/sandbox-control/lifecycle.test.ts - no issues
• services/cloud-agent-next/src/sandbox-session/SandboxSession.ts - no issues
• services/cloud-agent-next/src/sandbox-session/control-rpc.ts - no issues
• services/cloud-agent-next/src/telemetry/control-plane-failure-fence.test.ts - no issues
• services/cloud-agent-next/test/integration/worktree-deletion.test.ts - no issues
• services/session-ingest/src/services/worktree-deletion.test.ts - no issues
• services/session-ingest/src/services/worktree-deletion.ts - 2 issues
• services/session-ingest/src/session-ingest-rpc.ts - no issues

No memory leaks found: the new RPC path uses withTimeout, which clears its timer in finally, and no listeners, alarms, or unbounded collections are added. metadata.identity.sessionId is confirmed to be the workspace_<uuid> cloud-agent session id, so the new strict schema parses correctly. Markdown rule for images is not triggered (the added AGENTS.md section has no images).

Fix these issues in Kilo Cloud

---

_{Reviewed by deepseek-v4.1-flash · Input: 0 · Output: 0 · Cached: 0}

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