Sandbox (Code Execution) — foundations RFC

Status

*ccepted*— 20260509. Sector bootstrap (skeleton + 5 impl tickets) landed as part of /k-go services/ai audit wave (Modo C). Q1 resolved: Firecracker microVM as v1 default (sub200ms boot, 5MB overhead) with gVisor adapter as compatibility fallback. Q2 resolved: hardkill on quota breach with structured error and partialoutput preservation; softwarn is the wrong default for AI-generated code.

Summary

Execução isolada de código gerado — análogo E2BDaytonaModal sandboxes.

Motivation

services/ai/ai/backlog/pending/ tem ticket de "Pluggable execution sandbox backends" (#017). Agents geram código; sem sandbox = não rodam.

Scope

In

• Container runtime (Firecracker/gVisor)
• Language packs (PythonNodeBash)
• File IO
• Network policy
• Time limits

Out (yet)

• Long-running compute (escopo runtime)
• Distributed jobs

Initial design

Surfaces

• backend/ — Go API + sandbox orchestrator
• app/ — não aplicável v1

Key APIs

• POST /v1/sandbox/sessions — criar session
• POST /v1/sandbox/sessions/{id}/exec — executar código
• DELETE /v1/sandbox/sessions/{id} — destruir

Dependencies

• infra/data/kdb-blob — artifacts
• infra/observe — resource metrics
• services/ai/trace — exec spans

Relation to existing sectors

• Pré-requisito de tools que rodam código (kode, agents)
• Consumido por workflow (steps de código)

Selfhostedfirst analysis (5 gates)

• *1 Feature parity* zero como service
• *2 Performance* N/A
• *3 Stability* N/A
• *4 Capability* E2B-style FOSS spike viável
• *5 Critical-path readiness* desbloqueia kode tools agentes

Open questions

• Q1: Firecracker (overhead lower) vs gVisor (compat better)?
• Q2: Quota enforcement — hard kill vs soft warn?

Next steps

1. Ratificar esta RFC (1 round de comments).
2. Criar sector dir services/ai/sandbox/ com koder.toml, README.md, skeleton.
3. Abrir tickets de implementação em services/ai/sandbox/backlog/pending/.
4. Registrar em meta/docs/stack/registries/self-hosted-pairs.md se substituir externo.