fix: v0.2.1 — sandbox spawn reliability and auto-topup

[unifiedh]

Summary

• Auto-topup on 402: When sandbox creation fails with INSUFFICIENT_CREDITS, automatically top up credits via x402 and retry once (both orchestrator spawnAgent and spawn_child tool paths)
• Fix sandbox pricing tiers: Align createSandbox specs with valid Conway tiers (was sending 1 vCPU / 1024 MB / 5 GB which doesn't match any tier; now uses a lookup table)
• Remove sandbox deletion: Conway API no longer supports DELETE /v1/sandboxes — make deleteSandbox a no-op, clean up all callers
• Self-mod & replication fixes: Git-version source edits in repo root, self-replication tools target child sandbox not parent
• Version bump: 0.2.0 → 0.2.1

Test plan

• pnpm exec tsc --noEmit — zero type errors
• pnpm vitest run — 141 tests passing across replication, lifecycle, and tools-security suites
• Tests updated to reflect sandbox deletion removal

🤖 Generated with Claude Code

---

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 14 additional findings in Devin Review.

[devin-ai-integration]

🔴 Unhandled exception in spawn_child retry path causes original error to be lost

In the spawn_child tool's auto-topup retry logic, the retry spawnChild() call on line 1606 is not wrapped in a try-catch. If the retry throws (e.g., max children reached because the first attempt already created a child record in failed state, or any other spawn error), the exception escapes the outer catch block entirely, and the if (!child) throw err on line 1616 is never reached.

Detailed comparison with orchestrator's spawnAgent

The orchestrator's spawnAgent in src/agent/loop.ts:287-309 correctly wraps the retry spawn in its own try-catch:

try {
  const child = await retrySpawn(...);
  return { ... };
} catch (retryError) {
  logger.warn("Spawn retry after topup failed", { ... });
}

But the spawn_child tool in src/agent/tools.ts:1594-1613 does NOT wrap either topupForSandbox() or the retry spawnChild() in a try-catch:

const topup = await topupForSandbox({...});  // could throw
if (topup?.success) {
  child = await spawnChild(...);  // CAN THROW, escapes catch block
}

If the retry spawnChild throws, the new error propagates out of the catch block, the original err is lost, and the if (!child) throw err on line 1616 is never reached. This can result in confusing error messages and the failed first-attempt child record being left in an inconsistent state.

Impact: When a 402 topup succeeds but the retry spawn fails, the user gets an unhandled error from the retry instead of graceful fallback behavior. The original error context is lost.

Suggested change

	const topup = await topupForSandbox({
	apiUrl: ctx.config.conwayApiUrl,
	account: ctx.identity.account,
	error: err,
	});
	if (topup?.success) {
	const retryLifecycle = new ChildLifecycle(ctx.db.raw);
	const retryGenesis = generateGenesisConfig(ctx.identity, ctx.config, {
	name: args.name as string,
	specialization: args.specialization as string | undefined,
	message: args.message as string | undefined,
	});
	child = await spawnChild(
	ctx.conway,
	ctx.identity,
	ctx.db,
	retryGenesis,
	retryLifecycle,
	);
	}
	const topup = await topupForSandbox({
	apiUrl: ctx.config.conwayApiUrl,
	account: ctx.identity.account,
	error: err,
	});
	if (topup?.success) {
	try {
	const retryLifecycle = new ChildLifecycle(ctx.db.raw);
	const retryGenesis = generateGenesisConfig(ctx.identity, ctx.config, {
	name: args.name as string,
	specialization: args.specialization as string | undefined,
	message: args.message as string | undefined,
	});
	child = await spawnChild(
	ctx.conway,
	ctx.identity,
	ctx.db,
	retryGenesis,
	retryLifecycle,
	);
	} catch { /* retry failed, will throw original err below */ }
	}

---

Was this helpful? React with 👍 or 👎 to provide feedback.