Sandboxes para agentes de código: qué es Freestyle y por qué me importa

En 2005, cuando administraba el cyber café a los 14 años, tuve mi primera lección sobre procesos que corren sin supervisión. Un cliente había dejado un script ejecutándose — algo que descargaba archivos, decía — y cuando lo encontré media hora después había consumido todo el ancho de banda del local. Diez máquinas inutilizadas, gente enojada, yo sin saber ni por dónde empezar. Aprendí esa noche que lo que no podés ver ejecutarse, te puede romper todo.

Hoy pienso en eso cada vez que le doy permiso a Claude Code para que haga cambios en un proyecto real.

Sandboxes para coding agents: el problema que nadie nombra bien

Hay algo que los posts sobre agentes de código evitan decir directamente: el mayor riesgo no es que escriban código malo. El código malo lo revisás, lo revertís, lo arreglás. El riesgo real es la ejecución.

Un agente que escribe código incorrecto es un problema de calidad. Un agente que ejecuta rm -rf en el directorio equivocado, o hace un npm publish sin que vos lo pidas, o llama a una API con tus credenciales cacheadas — eso es un problema de seguridad. Y es un problema que muy poca gente está nombrando con la precisión que merece.

Cuando empecé a integrar agentes de código en mi workflow — hablo de proyectos reales, no de demos — lo primero que hice fue leer los logs de lo que se ejecutaba. No porque desconfíe de Claude específicamente. Porque soy el mismo tipo que tiró un servidor de producción en su primera semana con un rm -rf. Sé exactamente cuánto daño puede hacer un comando ejecutado en el contexto equivocado.

Eso me llevó a Freestyle.

Qué es Freestyle y qué resuelve concretamente

Freestyle llegó a Hacker News hace poco con 188 puntos — número que para mí es señal de que tocó un nervio real, no hype. La propuesta es directa: un sandbox de ejecución para agentes de código.

No es un concepto nuevo. Los sandboxes existen desde siempre en seguridad. Lo nuevo es aplicarlo específicamente al problema de los coding agents que necesitan:

1. Correr código arbitrario
2. Instalar dependencias
3. Ejecutar tests
4. Posiblemente hacer requests HTTP
5. Todo eso sin tocar tu sistema real

Freestyle te da un entorno de ejecución aislado donde el agente puede hacer todas esas cosas. Si rompe algo, rompe el sandbox. Tu máquina, tu base de datos, tus credenciales — siguen intactas.

La arquitectura, en términos simples:

// Lo que pasa SIN sandbox (tu situación actual, probablemente)
const agentRun = async (code: string) => {
  // El agente ejecuta directamente en tu proceso Node
  // Tiene acceso a process.env (tus secrets!)
  // Tiene acceso al filesystem real
  // Un npm install modifica tu node_modules real
  eval(code) // oversimplificado, pero conceptualmente esto
}

// Lo que propone Freestyle
const agentRunSandboxed = async (code: string) => {
  // Cada ejecución corre en un ambiente aislado
  // Filesystem efímero — muere con el sandbox
  // Variables de entorno controladas explícitamente
  // Network access configurable (podés bloquearlo)
  const sandbox = await Freestyle.createSandbox({
    runtime: 'node20',
    env: {
      // Solo los secrets que querés exponer, nada más
      DATABASE_URL: process.env.SANDBOX_DATABASE_URL,
    },
    network: {
      // Podés allowlist dominios específicos
      allowedHosts: ['api.openai.com']
    }
  })
  
  return await sandbox.execute(code)
}

Eso, en términos prácticos, es enorme.

Cómo mapea contra mi workflow actual

Mi stack hoy es Next.js, TypeScript, PostgreSQL en Railway, y Claude Code como asistente principal. Si querés el detalle completo, está en cómo construí juanchi.dev y en el post sobre el stack que elegiría en 2025.

Cuando uso Claude Code en modo interactivo — el que sugiere cambios y los aplica — hay una tensión constante. Le doy suficiente contexto para que sea útil, lo que incluye acceso al proyecto. Pero ese acceso, por definición, incluye cosas que no quiero que toque automáticamente.

Mi solución actual es básicamente manual: reviso cada cambio antes de confirmar, tengo git en cada paso, y nunca corro sugerencias directamente en el proyecto conectado a la base de datos de producción. Funciona. Pero es fricción.

Un sandbox como Freestyle cambia esa ecuación. En lugar de yo supervisando cada micro-acción, el sandbox define los límites estructuralmente. El agente puede correr lo que quiera dentro del sandbox. Afuera del sandbox, no existe.

Para alguien que está optimizando performance en producción con agentes ayudando a generar benchmarks y tests — esto es la diferencia entre "dejo que el agente pruebe" y "tengo miedo de que el agente pruebe".

Los errores comunes cuando integrás agentes sin sandbox

Voy a ser específico porque lo viví.

Error 1: Credentials en el contexto del agente

Si tu agente corre en el mismo proceso que tu app, tiene acceso a process.env. Todo. DATABASE_URL, API keys, tokens. Si el agente hace un request HTTP — por cualquier razón — puede estar exfiltrando esas credenciales. No porque sea malicioso. Porque el contexto no está delimitado.

// ❌ Esto parece inofensivo pero no lo es
const agente = new ClaudeAgent({
  cwd: process.cwd(), // Tiene acceso a todo el proyecto
  // process.env está disponible implícitamente
})

// ✅ Explicitá qué tiene y qué no tiene
const agente = new ClaudeAgent({
  cwd: '/tmp/sandbox-workspace', // Directorio aislado
  env: {
    NODE_ENV: 'test',
    // Solo lo que necesita para la tarea específica
  }
})

Error 2: npm install sin control

Un agente que puede instalar paquetes puede instalar cualquier cosa. Hay paquetes npm con código malicioso que se ejecuta en el install. Si el agente corre en tu máquina, ese código también corre en tu máquina.

Error 3: Confiar en que el agente "va a pedir permiso"

Algunos agentes tienen mecanismos de confirmación. Bien. Pero eso es UI, no seguridad. La seguridad tiene que estar en el aislamiento del sistema, no en la buena voluntad del modelo.

Error 4: Mezclar el database de desarrollo con el de producción

Esto aplica siempre, pero con agentes se vuelve crítico. Si el agente tiene acceso a tu connection string de producción — aunque sea "para leer" — estás un paso de un error costoso. Mis patrones de TypeScript incluyen helpers específicos para separar estos contextos, pero un sandbox lo resuelve a nivel infraestructura.

Lo que me genera ruido de Freestyle (la parte crítica)

Dicho todo lo anterior — y lo digo genuinamente porque creo en el problema que resuelve — hay cosas que me generan preguntas.

El cold start es real. Crear un sandbox por ejecución tiene latencia. Para flujos interactivos donde el agente hace muchas iteraciones pequeñas, esa latencia acumula. Freestyle menciona optimizaciones de startup, pero todavía no lo medí en un workflow real.

El pricing en producción está por verse. Sandboxes como servicio tiene costos de infraestructura no triviales. Si tu agente hace 50 ejecuciones por tarea, ese modelo de pricing escala diferente que una ejecución local.

La integración con Claude Code específicamente no está documentada claramente. O al menos no la encontré cuando lo exploré. Para mi workflow principal, necesito saber cómo conecta esto con el agente que ya estoy usando, no con un agente nuevo.

No resuelve el problema de output. El sandbox aísla la ejecución, pero el código que el agente produce igual termina en tu codebase. El sandbox te salva del daño durante el proceso; el code review te salva del daño en el resultado. Los dos son necesarios.

Lo que haría diferente: antes de adoptar Freestyle como dependencia principal, construiría primero con Docker un sandbox básico propio — algo que ya cubrí en el post de Docker para Node.js — para entender los trade-offs antes de delegar esa responsabilidad a un servicio externo.

FAQ: Sandboxes para coding agents

¿Qué es un sandbox para coding agents exactamente? Es un entorno de ejecución aislado donde un agente de código puede correr comandos, instalar dependencias y ejecutar scripts sin acceder al sistema host. Piensalo como una VM efímera: todo lo que pasa adentro, muere adentro. Tu filesystem real, tus variables de entorno y tu base de datos no son accesibles a menos que vos explícitamente lo permitas.

¿Por qué no alcanza con correr el agente en Docker localmente? Docker es una opción válida y es lo que muchos hacemos hoy. El valor de Freestyle específicamente es que abstrae la infraestructura del sandbox y la expone como API, con lifecycle management, networking configurable y soporte para múltiples runtimes. Docker local funciona, pero tiene fricción de setup y no tiene las mismas garantías de aislamiento de red out-of-the-box.

¿Freestyle es open source o es un servicio? Es un servicio con SDK. El SDK es open source, la infraestructura que corre los sandboxes es managed. Modelo similar a Vercel con Next.js: podés correrlo vos mismo, pero el servicio managed es el punto de entrada natural.

¿Funciona con cualquier agente de código o solo con algunos específicos? Conceptualmente funciona con cualquier agente que necesite ejecutar código — Claude Code, GPT Engineer, Devin, o tu propio agente custom. La integración concreta depende de cómo tu agente maneja la ejecución. Si el agente llama a un subprocess o a una API de ejecución, podés redirigir esas llamadas a Freestyle. Si el agente tiene un modelo de ejecución muy acoplado, la integración es más compleja.

¿Un sandbox resuelve todos los problemas de seguridad de los coding agents? No. El sandbox resuelve el problema de ejecución no supervisada. No resuelve: código malicioso que el agente produce y vos deployás, prompt injection si el agente procesa input externo, o el problema de qué hacés con el output del sandbox una vez que lo tenés. Es una capa de seguridad, no la seguridad completa.

¿Vale la pena para proyectos personales o solo para equipos? Depende de cuánto usás agentes de código. Si usás Claude Code o similar ocasionalmente para sugerencias de código que vos aplicás manualmente, probablemente no necesitás un sandbox formal. Si tenés agentes corriendo de forma autónoma — haciendo commits, corriendo tests, instalando deps — un sandbox deja de ser nice-to-have y se vuelve necesario. Para mi uso actual está en el límite. Cuando pase a workflows más autónomos, voy directo al sandbox.

Conclusión: el miedo correcto

El cyber café me enseñó que el problema no es lo que ves correr — es lo que corre sin que lo estés mirando.

Los coding agents son increíblemente útiles. Los uso todos los días y no volvería atrás. Pero hay una diferencia entre usarlos como autocomplete inteligente y usarlos como agentes autónomos con acceso a tu entorno real. Esa diferencia importa.

Freestyle está apuntando al problema correcto. El sandbox no es paranoia — es el mismo principio que me llevó a tener bases de datos separadas por ambiente, a usar secrets managers en lugar de .env en producción, y a nunca correr código de terceros con más permisos de los necesarios. Principios que cualquiera que haya trabajado en infraestructura real entiende visceralmente.

Lo que haría hoy: si ya estás usando agentes en proyectos reales, revisá qué acceso tienen a tu entorno. Si tienen acceso a process.env completo, a tu database real, o corren en el mismo proceso que tu app — eso es técnicamente un sandbox cero. Empezá por ahí, con Docker o con Freestyle, antes de que el problema sea más que teórico.

El App Router de Next.js me enseñó que a veces te enojás dos semanas con la abstracción correcta. No quiero repetir ese error con los sandboxes para agentes.