flar

FLAR est le Fast Light Agent Restrictor. Il fonctionne sur des roches appelées gars.

C'est un outil CLI simple et léger en Go pour exécuter des CLI d'agents de codage (comme Claude Code, Antigravity, Codex, Copilot et Reasonix) en toute sécurité dans des sandbox Bubblewrap (bwrap) isolés.

Le but est de instantanément et sans configuration compliquée, bubblewrap un agent IA afin qu'il n'ait accès qu'au projet sur lequel vous travaillez. Cela protège contre les injections de prompt ainsi que les problèmes de chaîne d'approvisionnement dans les bibliothèques que l'agent pourrait importer dans votre projet sans vérification suffisante (ou par malchance). La seule information sensible accessible est les propres détails d'authentification de l'agent et l'historique de chat du projet.

La plupart des agents ont une fonctionnalité de « sandbox », mais elle est assez poreuse et l'agent lui-même peut étendre la portée de ce qui est accessible. Et, bien sûr, les vulnérabilités de chaîne d'approvisionnement ne sont pas soumises à la sandbox de l'agent. flar est totalement imperméable à l'agent, et le rayon d'explosion des attaques sur la chaîne d'approvisionnement est étroitement limité.

Bubblewrap est extrêmement bien testé et activement maintenu. Il est utilisé par Flatpack et de nombreux autres projets pour des conteneurs légers. flar est beaucoup moins bien testé, et utilisé par moi depuis quelques jours.

Fonctionnalités

• Sandbox Bubblewrap : Exécute l'agent dans un espace de noms utilisateur non privilégié en utilisant un répertoire racine propre (tmpfs). Les chemins système (/usr, /bin, /lib, /lib64, etc.) sont montés en lecture seule depuis l'hôte, garantissant que les paquets de l'hôte sont immédiatement disponibles sans gestion d'image conteneur.
• Isolation stricte du système de fichiers : Seul le répertoire du projet cible est monté en liaison en lecture-écriture. Le reste du répertoire personnel de l'hôte est masqué, protégeant les clés SSH, les configurations de shell et les fichiers personnels contre les attaques par injection de prompt.
• Sandbox réseau :
  • Mode isolé (par défaut) : L'espace de noms réseau est désolidarisé. L'accès Internet est tunnelé via un proxy HTTP/HTTPS côté hôte qui effectue la résolution DNS sur l'hôte et filtre le trafic vers les adresses IP locales/loopback.
  • Redirection de ports : Exposez sélectivement des services locaux (par exemple bases de données, modèles llama.cpp) dans la sandbox en mappant des ports spécifiques sur le localhost de l'hôte.
  • Mode hôte : Option pour partager l'espace de noms réseau de l'hôte pour un accès sans restriction.
• Options de contournement dangereuses : Injecte automatiquement des drapeaux (comme --dangerously-skip-permissions pour Claude/agy ou pour Codex) afin que les agents s'exécutent sans interruptions d'approbation en cours d'exécution. Peut être désactivé avec .

Construction et installation

Dépendances

Assurez-vous que bwrap (Bubblewrap) est installé sur votre système hôte :

# Sur Fedora/RHEL
sudo dnf install bubblewrap

# Sur Debian/Ubuntu
sudo apt install bubblewrap

Compilation et installation

Pour compiler flar à partir des sources :

go build -o `flar` .

Pour l'installer :

mv `flar` ~/.local/bin/

Utilisation

Exécutez flar dans votre dossier de projet ou spécifiez le chemin :

flar [flags] [path/to/project] [extra agent args/prompts...]

Drapeaux

• -m : Spécifie l'agent à exécuter (claude, codex, agy, copilot, reasonix). Par défaut, il vérifie les configurations hôtes disponibles ou les variables d'environnement.
• -ask : Ne pas sauter les permissions/approbations (forcer l'agent à demander la permission).
• -network : Mode réseau : isolated (par défaut) ou host.
• -allow-port : Autoriser un port TCP local spécifique (par exemple 8080, 11434) à travers la sandbox réseau isolée. Peut être spécifié plusieurs fois.
• -v : Activer la journalisation détaillée.

Fichier de configuration (.flar.json)

Vous pouvez configurer les options par projet dans <projet>/.flar.json ou globalement dans ~/.config/flar/config.json :

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

Identifiants

Comme seule une copie temporaire de votre configuration est montée, les agents s'exécutent authentifiés en utilisant votre session hôte existante sans toucher aux originaux. La plupart des agents conservent leur session dans des fichiers que flar copie directement :

• Claude : ~/.claude/ (y compris .credentials.json) et ~/.claude.json, le fichier de premier niveau contenant l'état d'intégration et l'identité du compte. Les deux sont requis ; avec seulement les identifiants, Claude traite la sandbox comme une nouvelle installation et demande une connexion.
• Codex / Copilot : ~/.codex/, ~/.copilot/ et la configuration GitHub CLI.

Trousseau Antigravity (agy)

agy est l'exception : il ne stocke pas son jeton dans un fichier. Il le conserve dans le trousseau du système, accessible via l'API Secret Service freedesktop sur le bus de session D-Bus. La sandbox n'a pas de bus de session, donc une configuration naïve échoue avec authentication failed or timed out.

flar gère cela spécialement :

1. Sur l'hôte, il extrait uniquement le jeton agy (élément de trousseau service=gemini, username=antigravity) en utilisant secret-tool, et l'écrit dans un fichier 0600 dans le répertoire de configuration temporaire.
2. À l'intérieur de la sandbox, il exécute un Service Secret minimal et autonome (flar --internal-secretsvc) sur un socket Unix privé, pointé par DBUS_SESSION_BUS_ADDRESS. Il sert ce seul jeton et rien d'autre.

L'agent peut atteindre exactement son propre jeton – pas le reste de votre trousseau (mots de passe de navigateur, secrets d'autres applications, etc.). L'implémentation parle directement le protocole filaire D-Bus, donc elle n'a pas besoin de gnome-keyring ou dbus-daemon dans la sandbox.

Exigences et mises en garde :

• L'extraction côté hôte nécessite secret-tool (libsecret) installé sur l'hôte. S'il est absent ou que le jeton n'est pas trouvé, flar saute le pont et agy revient à son invite de connexion normale.
• Tout agent authentifié peut, par définition, lire son propre jeton ; une attaque par injection de prompt pourrait l'exfiltrer. C'est inhérent au fait de fonctionner authentifié. Le pont de trousseau limite l'exposition à ce seul jeton plutôt qu'à l'intégralité de votre trousseau.

Persistance et reprise de session

Comme la sandbox monte une copie temporaire de votre configuration, tout ce qu'un agent y écrirait disparaîtrait normalement à la sortie – y compris la conversation qu'il vient d'avoir. flar lie le stockage des transcriptions de chaque agent à l'hôte afin que les sessions persistent et puissent être reprises plus tard, tout en gardant l'historique des autres projets hors de la sandbox.

• Claude : les transcriptions vivent dans un répertoire par projet (~/.claude/projects/<slug-du-projet>/). flar monte uniquement le répertoire du projet actuel depuis l'hôte sur la configuration copiée, donc claude --resume ne voit que les sessions de ce projet et rien d'autre. Attention, cela signifie qu'une injection de prompt stockée dans l'historique pourrait encore être un risque ; si vous reprenez une session qui contient une injection de prompt active, le rayon d'explosion devient infiniment plus grand si vous exécutez claude en dehors de flar. Je pense que la commodité l'emporte sur le risque ; pour les projets qui présentent ce genre de risque, exécutez-les toujours dans flar.

• Codex CLI : Codex stocke les transcriptions dans des répertoires par date sous ~/.codex/sessions/ et les indexe dans la base globale state_5.sqlite ; les deux enregistrent le cwd de chaque fil, mais les répertoires sur disque mélangent les projets. flar donne à chaque espace de travail un home Codex fantôme sous $XDG_STATE_HOME/flar/codex/<slug-du-projet>/, en se repliant sur lorsque cette variable n'est pas définie. Lors de la première utilisation, il amorce ce home avec uniquement les fichiers de transcription correspondants, les lignes SQLite et les entrées d'historique de prompt. Le home fantôme est ensuite monté comme , de sorte que les nouvelles sessions persistent sans exposer un autre projet à .

~/.copilot/.flar/<slug-du-projet>/

Lors de la première utilisation, flar amorce ce home fantôme avec uniquement les sessions dont le cwd stocké correspond à l'espace de travail actuel, copiant à la fois les lignes SQLite pertinentes et les répertoires session-state/ correspondants. Après cela, l'ensemble du home fantôme est monté en liaison comme ~/.copilot à l'intérieur de la sandbox, donc copilot --continue peut reprendre uniquement les sessions de cet espace de travail, et les nouvelles sessions y persistent en toute sécurité.

• Antigravity (agy) : comme pour Copilot, les sessions sont « bifurquées » lors du premier lancement dans un projet par flar, et ne sont plus partagées avec agy s'exécutant en dehors de flar.

agy ne sépare pas les conversations par projet sur le disque. Toutes les conversations pour tous les projets vivent dans un seul magasin plat sous ~/.gemini/antigravity-cli/ (conversations/, brain/, implicit/), identifiées uniquement par un UUID, l'espace de travail propriétaire étant enregistré à l'intérieur de blobs de conversation opaques. Un index de récence (cache/last_conversations.json) mappe chaque espace de travail à sa conversation la plus récente, ce que agy --continue suit.

Lier ce magasin dans la sandbox tel quel permettrait à un agy sandboxé de reprendre – via --continue, le sélecteur interactif ou un --conversation <ID> explicite – une conversation appartenant à un projet différent, fuyant ainsi ce qui y a été collé. Pour éviter cela, flar donne à chaque espace de travail son propre magasin limité :

~/.gemini/antigravity-cli/.flar/<slug-du-projet>/

Ce répertoire est monté en liaison sur conversations/, brain/, implicit/, history.jsonl et cache/last_conversations.json à l'intérieur de la sandbox. Une sandbox ouverte sur le projet A ne peut donc voir que les conversations du projet A. Les nouvelles sessions s'accumulent dans le magasin limité et sont reprises lors de l'exécution suivante.

La première fois que flar exécute agy dans un projet, il amorce le magasin limité de ce projet à partir de votre historique hôte existant – mais uniquement avec les conversations que agy lui-même attribue à cet espace de travail (déterminé à partir de last_conversations.json et history.jsonl en texte clair, jamais en analysant les blobs de conversation). Après cet amorçage unique, le magasin limité est indépendant : les nouvelles sessions vivent uniquement dans le magasin limité, et les changements ultérieurs côté hôte ne sont pas importés.

• Reasonix : Exactement comme Claude Code. Reasonix conserve l'historique de chaque projet dans son propre sous-répertoire, donc il peut être monté en liaison de la même manière que Claude Code, avec la même mise en garde.

Conséquences à connaître :

• Copilot CLI : comme pour agy, le home fantôme limité devient un monde séparé par projet après l'amorçage initial. Les sessions que vous démarrez avec Copilot en dehors de flar ne sont pas importées dans flar ultérieurement, et les sessions que vous démarrez à l'intérieur de flar sont sauvegardées dans le home fantôme limité plutôt que dans le magasin Copilot global de l'hôte.
• Les sessions que vous démarrez avec agy en dehors de flar ne sont (à l'exception de l'amorçage initial) pas visibles à l'intérieur de flar, et vice versa. C'est délibéré – l'historique agy de flar est un monde séparé par projet.
• Codex suit la même règle : après l'amorçage unique, les historiques Codex encapsulés et non encapsulés sont indépendants.
• Une conversation que les propres index de agy n'ont jamais attribuée à l'espace de travail actuel n'est pas amorcée, par conception. La valeur par défaut sûre est de la retenir plutôt que de risquer d'exposer les données d'un autre projet.
• Les répertoires .flar/ appartenant aux agents sont exclus des copies de configuration pour la compatibilité, et l'état appartenant à réside sous (ou ), en dehors des répertoires de configuration gérés par l'agent.

Sécurité réseau et ports locaux

En mode réseau isolé, l'environnement de l'agent n'a pas d'accès direct aux interfaces réseau de l'hôte.

• Accès Internet : Fonctionne automatiquement pour les requêtes HTTP/HTTPS (comme la connexion aux LLM cloud comme Anthropic ou Gemini) en utilisant les variables d'environnement HTTP_PROXY et HTTPS_PROXY.
• Restrictions localhost : Les requêtes vers localhost ou les IP de boucle locale via le proxy sont bloquées.
• Exposition de services locaux : Pour permettre à l'agent d'atteindre une base de données locale ou un LLM local (par exemple Ollama sur 127.0.0.1:11434), spécifiez le port avec -allow-port 11434 ou la configuration allow_ports. Un redirectionneur de boucle locale sécurisé liera 127.0.0.1:11434 à l'intérieur de la sandbox et transférera le trafic vers l'hôte.