flar

FLAR es el Restrictor de Agentes Ligero y Rápido. Funciona sobre rocas llamadas gars.

Es una herramienta CLI simple y ligera en Go para ejecutar CLIs de agentes de codificación (como Claude Code, Antigravity, Codex, Copilot y Reasonix) de forma segura dentro de entornos aislados de Bubblewrap (bwrap) aislados.

El propósito es instantáneamente y sin configuración complicada, envolver en bubblewrap a un agente de IA para que solo tenga acceso al proyecto en el que estás trabajando. Esto protege contra inyecciones de instrucciones, así como contra problemas en la cadena de suministro de bibliotecas que el agente pueda incorporar a tu proyecto sin la verificación suficiente (o simplemente por mala suerte). La única información sensible accesible son los propios detalles de autenticación del agente y el historial de chat del proyecto.

La mayoría de los agentes tienen una función de "entorno aislado", pero es bastante porosa y el propio agente puede expandir el alcance de lo que es accesible. Y, por supuesto, las vulnerabilidades de la cadena de suministro no están sujetas al entorno aislado del agente. flar es completamente inmune al agente, y el radio de explosión de los ataques a la cadena de suministro está estrictamente limitado.

Bubblewrap está extremadamente bien probado y se mantiene activamente. Es utilizado por Flatpak y muchos otros proyectos para contenedores ligeros. flar está mucho menos probado, y lo he usado yo durante un par de días.

Características

• Entorno Aislado de Bubblewrap: Ejecuta el agente en un espacio de nombres de usuario sin privilegios usando un directorio raíz limpio (tmpfs). Las rutas del sistema (/usr, /bin, /lib, /lib64, etc.) se montan como solo lectura desde el anfitrión, asegurando que los paquetes del anfitrión estén disponibles inmediatamente sin necesidad de gestión de imágenes de contenedor.
• Aislamiento Estricto del Sistema de Archivos: Solo el directorio del proyecto objetivo se monta como lectura-escritura. El resto del directorio home del anfitrión está oculto, protegiendo las claves SSH, las configuraciones de shell y los archivos personales de ataques de inyección de instrucciones.
• Aislamiento de Red:
  • Modo Aislado (Predeterminado): El espacio de nombres de red se descomparte. El acceso a Internet se canaliza a través de un proxy HTTP/HTTPS del lado del anfitrión que realiza la resolución DNS en el anfitrión y filtra el tráfico hacia direcciones IP locales/loopback.
  • Reenvío de Puertos: Exponer selectivamente servicios locales (por ejemplo, bases de datos, modelos llama.cpp) dentro del entorno aislado mapeando puertos específicos al localhost del anfitrión.
  • Modo Anfitrión: Opción para compartir el espacio de nombres de red del anfitrión para acceso sin restricciones.
• Opciones de Bypass Peligroso: Inyecta automáticamente indicadores (como --dangerously-skip-permissions para Claude/agy o para Codex) para que los agentes se ejecuten sin interrupciones de aprobación en tiempo de ejecución. Se puede deshabilitar con .

Compilar e Instalar

Dependencias

Asegúrate de que bwrap (Bubblewrap) esté instalado en tu sistema anfitrión:

# En Fedora/RHEL
sudo dnf install bubblewrap

# En Debian/Ubuntu
sudo apt install bubblewrap

Compilar e Instalar

Para compilar flar desde el código fuente:

go build -o `flar` .

Para instalar:

mv `flar` ~/.local/bin/

Uso

Ejecuta flar en la carpeta de tu proyecto o especifica la ruta:

flar [flags] [ruta/al/proyecto] [argumentos/instrucciones adicionales del agente...]

Indicadores

• -m: Especifica el agente a ejecutar (claude, codex, agy, copilot, reasonix). Por defecto, verifica las configuraciones del anfitrión disponibles o las variables de entorno.
• -ask: No omitir permisos/aprobaciones (forzando al agente a pedir permiso).
• -network: Modo de red: isolated (predeterminado) o host.
• -allow-port: Permitir un puerto TCP local específico (por ejemplo, 8080, 11434) a través del entorno aislado de red. Se puede especificar varias veces.
• -v: Habilitar registro detallado.

Archivo de configuración (.flar.json)

Puedes configurar opciones por proyecto en <proyecto>/.flar.json o globalmente en ~/.config/flar/config.json:

{
  "agent": "claude",
  "ask": false,
  "network": "isolated",
  "allow_ports": [5432, 11434]
}

Credenciales

Debido a que solo se monta una copia temporal de tu configuración, los agentes se ejecutan autenticados utilizando tu sesión anfitriona existente sin tocar los originales. La mayoría de los agentes mantienen su sesión en archivos que flar copia directamente:

• Claude: ~/.claude/ (incluyendo .credentials.json) y ~/.claude.json, el archivo de nivel superior que contiene el estado de incorporación y la identidad de la cuenta. Ambos son necesarios; solo con las credenciales, Claude trata el entorno aislado como una instalación nueva y solicita inicio de sesión.
• Codex / Copilot: ~/.codex/, ~/.copilot/ y la configuración de GitHub CLI.

Llavero de Antigravity (agy)

agy es la excepción: no almacena su token en un archivo. Lo mantiene en el llavero del SO, leído a través de la API del Servicio Secreto de freedesktop sobre el bus de sesión de D-Bus. El entorno aislado no tiene bus de sesión, por lo que una configuración ingenua falla con authentication failed or timed out.

flar maneja esto de manera especial:

1. En el anfitrión, extrae solo el token de agy (elemento del llavero service=gemini, username=antigravity) usando secret-tool, y lo escribe en un archivo 0600 en el directorio de configuración temporal.
2. Dentro del entorno aislado, ejecuta un Servicio Secreto mínimo y autónomo (flar --internal-secretsvc) en un socket Unix privado, apuntado por DBUS_SESSION_BUS_ADDRESS. Sirve ese único token y nada más.

El agente puede alcanzar exactamente su propio token — no el resto de tu llavero (contraseñas del navegador, secretos de otras aplicaciones, etc.). La implementación habla el protocolo de cable D-Bus directamente, por lo que no necesita gnome-keyring ni dbus-daemon dentro del entorno aislado.

Requisitos y advertencias:

• La extracción del lado del anfitrión necesita secret-tool (libsecret) instalado en el anfitrión. Si está ausente o no se encuentra el token, flar omite el puente y agy vuelve a su mensaje de inicio de sesión normal.
• Cualquier agente autenticado puede, por definición, leer su propio token; un ataque de inyección de instrucciones podría exfiltrarlo. Esto es inherente a ejecutarse autenticado. El puente de llavero limita la exposición a ese único token en lugar de a todo tu llavero.

Persistencia y reanudación de sesiones

Debido a que el entorno aislado monta una copia temporal de tu configuración, cualquier cosa que un agente escriba allí normalmente desaparecería al salir — incluyendo la conversación que acaba de tener. flar vincula el almacenamiento de transcripciones de cada agente de vuelta al anfitrión para que las sesiones persistan y puedan reanudarse más tarde, mientras mantiene el historial de otros proyectos fuera del entorno aislado.

• Claude: las transcripciones viven en un directorio por proyecto (~/.claude/projects/<slug-del-proyecto>/). flar vincula solo el directorio del proyecto actual desde el anfitrión sobre la configuración copiada, por lo que claude --resume ve las sesiones de este proyecto y nada más. Ten en cuenta que esto significa que una inyección de instrucciones almacenada en el historial podría seguir siendo un riesgo; si reanudas una sesión que contiene una inyección de instrucciones funcional, el radio de explosión se vuelve infinitamente mayor si ejecutas claude fuera de flar. Creo que la conveniencia supera el riesgo; para cualquier proyecto que tenga ese tipo de riesgo, simplemente ejecútalo siempre en flar.

• Codex CLI: Codex almacena transcripciones bajo directorios basados en fecha en ~/.codex/sessions/ y las indexa en el state_5.sqlite global; ambos registran el cwd de cada hilo, pero los directorios en disco mezclan proyectos. flar le da a cada espacio de trabajo un directorio home de Codex sombra bajo $XDG_STATE_HOME/flar/codex/<slug-del-proyecto>/, recurriendo a cuando esa variable no está definida. En el primer uso, siembra ese home sombra solo con archivos de transcripción coincidentes, filas de SQLite y entradas del historial de instrucciones. Luego, el home sombra se monta como , por lo que las nuevas sesiones persisten sin exponer otro proyecto a .

~/.copilot/.flar/<slug-del-proyecto>/

En el primer uso, flar siembra ese home sombra solo con las sesiones cuyo cwd almacenado coincide con el espacio de trabajo actual, copiando tanto las filas de SQLite relevantes como los directorios session-state/ coincidentes. Después de eso, todo el home sombra se monta como ~/.copilot dentro del entorno aislado, por lo que copilot --continue puede reanudar solo las sesiones de este espacio de trabajo, y las nuevas sesiones persisten allí de forma segura.

• Antigravity (agy): al igual que con Copilot, las sesiones se "bifurcan" en la primera ejecución en un proyecto por flar, y ya no se comparten con agy ejecutándose fuera de flar.

agy no separa las conversaciones por proyecto en disco. Cada conversación de cada proyecto vive en un único almacén plano bajo ~/.gemini/antigravity-cli/ (conversations/, brain/, implicit/), identificadas solo por un UUID, con el espacio de trabajo propietario registrado dentro de blobs de conversación opacos. Un índice de actualidad (cache/last_conversations.json) mapea cada espacio de trabajo a su conversación más reciente, que es lo que sigue agy --continue.

Vincular ese almacén dentro del entorno aislado tal cual permitiría que un agy en entorno aislado reanude — mediante --continue, el selector interactivo, o un --conversation <ID> explícito — una conversación perteneciente a un proyecto diferente, filtrando lo que se haya pegado en ella. Para evitar eso, flar le da a cada espacio de trabajo su propio almacén con alcance:

~/.gemini/antigravity-cli/.flar/<slug-del-proyecto>/

Este directorio se monta sobre conversations/, brain/, implicit/, history.jsonl y cache/last_conversations.json dentro del entorno aislado. Un entorno aislado abierto en el proyecto A solo puede ver las conversaciones del proyecto A. Las nuevas sesiones se acumulan en el almacén con alcance y se pueden reanudar en la siguiente ejecución.

La primera vez que flar ejecuta agy en un proyecto, siembra el almacén con alcance de ese proyecto a partir de tu historial anfitrión existente — pero solo con las conversaciones que agy mismo atribuye a este espacio de trabajo (determinado a partir de last_conversations.json y history.jsonl en texto plano, nunca analizando los blobs de conversación). Después de esa siembra única, el almacén con alcance es independiente: las nuevas sesiones viven solo en el almacén con alcance, y los cambios posteriores del lado del anfitrión no se incorporan.

• Reasonix: Igual que Claude Code. Reasonix mantiene el historial de cada proyecto en su propio subdirectorio, por lo que se puede montar de la misma manera que Claude Code, con la misma advertencia.

Consecuencias a tener en cuenta:

• Copilot CLI: al igual que con agy, el home sombra con alcance se convierte en un mundo separado por proyecto después de la siembra inicial. Las sesiones que inicies con Copilot fuera de flar no se incorporan a flar más tarde, y las sesiones que inicies dentro de flar se guardan en el home sombra con alcance en lugar del almacén global de Copilot del anfitrión.
• Las sesiones que inicies con agy fuera de flar no son visibles dentro de flar (aparte de la siembra inicial), y viceversa. Esto es deliberado — el historial de agy de flar es un mundo separado y por proyecto.
• Codex sigue la misma regla: después de la siembra única, los historiales de Codex envuelto y no envuelto son independientes.
• Una conversación que los propios índices de agy nunca atribuyeron al espacio de trabajo actual no se siembra, por diseño. El valor predeterminado seguro es retenerla en lugar de arriesgarse a exponer datos de otro proyecto.
• Los directorios .flar/ propiedad del agente se excluyen de las copias de configuración por compatibilidad, y el estado propiedad de flar vive bajo $XDG_STATE_HOME/flar/ (o ), fuera de los directorios de configuración gestionados por el agente.

Seguridad de Red y Puertos Locales

En el modo de red aislado, el entorno del agente no tiene acceso directo a las interfaces de red del anfitrión.

• Acceso a Internet: Funciona automáticamente para solicitudes HTTP/HTTPS (como la conexión a LLMs en la nube como Anthropic o Gemini) utilizando las variables de entorno HTTP_PROXY y HTTPS_PROXY.
• Restricciones de Localhost: Las solicitudes a localhost o IPs de loopback a través del proxy están bloqueadas.
• Exposición de Servicios Locales: Para permitir que el agente acceda a una base de datos local o LLM local (por ejemplo, Ollama en 127.0.0.1:11434), especifica el puerto usando -allow-port 11434 o la configuración allow_ports. Un reenviador de loopback seguro vinculará 127.0.0.1:11434 dentro del entorno aislado y retransmitirá el tráfico al anfitrión.