flar

FLAR è il Fast Light Agent Restrictor. Funziona su rocce chiamate gars.

È uno strumento CLI semplice e leggero in Go per eseguire CLI di agenti di codifica (come Claude Code, Antigravity, Codex, Copilot e Reasonix) in modo sicuro all'interno di sandbox Bubblewrap (bwrap) isolate.

Lo scopo è quello di immediatamente e senza complicata configurazione, eseguire bubblewrap su un agente AI in modo che abbia accesso solo al progetto su cui stai lavorando. Questo protegge da iniezioni di prompt e da problemi della supply chain nelle librerie che l'agente potrebbe introdurre nel tuo progetto senza sufficiente verifica (o solo per sfortuna). Le uniche informazioni sensibili accessibili sono i dettagli di autenticazione dell'agente stesso e la cronologia delle chat per il progetto.

La maggior parte degli agenti ha una funzionalità "sandbox", ma è piuttosto porosa e l'agente stesso può espandere l'ambito di ciò che è accessibile. E, naturalmente, le vulnerabilità della supply chain non sono soggette alla sandbox dell'agente. flar è completamente impermeabile all'agente, e il raggio di esplosione degli attacchi alla supply chain è strettamente limitato.

Bubblewrap è estremamente ben testato e mantenuto attivamente. È utilizzato da Flatpack e molti altri progetti per container leggeri. flar è molto meno testato, e usato da me per un paio di giorni.

Caratteristiche

• Sandbox Bubblewrap: Esegue l'agente in un namespace utente non privilegiato utilizzando una directory root pulita (tmpfs). I percorsi di sistema (/usr, /bin, /lib, /lib64, ecc.) sono montati in sola lettura dall'host, garantendo che i pacchetti host siano immediatamente disponibili senza gestione di immagini container.
• Isolamento Rigoroso del Filesystem: Solo la directory del progetto di destinazione è montata in lettura-scrittura. Il resto della home directory dell'host è nascosto, proteggendo chiavi ssh, configurazioni shell e file personali da attacchi di iniezione del prompt.
• Sandboxing di Rete:
  • Modalità Isolata (Predefinita): Il namespace di rete è separato. L'accesso a Internet è tunnelizzato attraverso un proxy HTTP/HTTPS lato host che esegue la risoluzione DNS sull'host e filtra il traffico verso indirizzi IP locali/loopback.
  • Port Forwarding: Esporre selettivamente servizi locali (ad es. database, modelli llama.cpp) nella sandbox mappando porte specifiche su localhost dell'host.
  • Modalità Host: Opzione per condividere il namespace di rete dell'host per accesso senza restrizioni.
• Opzioni di Bypass Pericolose: Inietta automaticamente flag (come --dangerously-skip-permissions per Claude/agy o --dangerously-bypass-approvals-and-sandbox per Codex) in modo che gli agenti vengano eseguiti senza interruzioni di approvazione in fase di esecuzione. Può essere disabilitato con .

Build e Installazione

Dipendenze

Assicurati che bwrap (Bubblewrap) sia installato sul tuo sistema host:

# Su Fedora/RHEL
sudo dnf install bubblewrap

# Su Debian/Ubuntu
sudo apt install bubblewrap

Compila e Installa

Per compilare flar dal sorgente:

go build -o `flar` .

Per installare:

mv `flar` ~/.local/bin/

Utilizzo

Esegui flar nella cartella del tuo progetto o specifica il percorso:

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

Flag

• -m: Specifica l'agente da eseguire (claude, codex, agy, copilot, reasonix). Predefinito: controlla le configurazioni host disponibili o le variabili d'ambiente.
• -ask: Non saltare permessi/approvazioni (costringendo l'agente a chiedere permesso).
• -network: Modalità di rete: isolated (predefinita) o host.
• -allow-port: Consenti una porta TCP locale specifica (ad es. 8080, 11434) attraverso la sandbox di rete isolata. Può essere specificato più volte.
• -v: Abilita logging verboso.

File di configurazione (.flar.json)

Puoi configurare le opzioni per progetto in <progetto>/.flar.json o globalmente in ~/.config/flar/config.json:

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

Credenziali

Poiché viene montata solo una copia temporanea della tua configurazione, gli agenti vengono eseguiti autenticati utilizzando la sessione host esistente senza toccare gli originali. La maggior parte degli agenti mantiene la propria sessione in file che flar copia direttamente:

• Claude: ~/.claude/ (incluso .credentials.json) e ~/.claude.json, il file di primo livello che contiene lo stato di onboarding e l'identità dell'account. Entrambi sono necessari; solo con le credenziali, Claude tratta la sandbox come una nuova installazione e richiede il login.
• Codex / Copilot: ~/.codex/, ~/.copilot/ e la configurazione di GitHub CLI.

Keyring di Antigravity (agy)

agy è l'eccezione: non memorizza il suo token in un file. Lo mantiene nel keyring del sistema operativo, letto tramite l'API Secret Service di freedesktop sul bus di sessione D-Bus. La sandbox non ha un bus di sessione, quindi una configurazione ingenua fallisce con authentication failed or timed out.

flar gestisce questo in modo speciale:

1. Sull'host, estrae solo il token agy (elemento keyring service=gemini, username=antigravity) usando secret-tool, e lo scrive in un file 0600 nella directory di configurazione temporanea.
2. All'interno della sandbox, esegue un Secret Service minimale e autonomo (flar --internal-secretsvc) su un socket Unix privato, puntato da DBUS_SESSION_BUS_ADDRESS. Serve quel singolo token e nient'altro.

L'agente può raggiungere esattamente il proprio token — non il resto del tuo keyring (password del browser, segreti di altre app, ecc.). L'implementazione parla direttamente il protocollo wire D-Bus, quindi non necessita di nessun gnome-keyring o dbus-daemon all'interno della sandbox.

Requisiti e avvertenze:

• L'estrazione lato host necessita di secret-tool (libsecret) installato sull'host. Se è assente o il token non viene trovato, flar salta il bridge e agy torna al suo normale prompt di login.
• Qualsiasi agente autenticato può, per definizione, leggere il proprio token; un attacco di iniezione del prompt potrebbe esfiltrarlo. Questo è intrinseco all'esecuzione autenticata. Il keyring bridge limita l'esposizione a quel singolo token piuttosto che all'intero keyring.

Persistenza e ripristino della sessione

Poiché la sandbox monta una copia temporanea della tua configurazione, qualsiasi cosa un agente scriva lì normalmente scomparirebbe all'uscita — inclusa la conversazione appena avvenuta. flar collega lo storage dei trascritti di ciascun agente all'host in modo che le sessioni persistano e possano essere riprese in seguito, mantenendo fuori dalla sandbox la cronologia di altri progetti.

• Claude: i trascritti vivono in una directory per progetto (~/.claude/projects/<slug-progetto>/). flar monta solo la directory del progetto corrente dall'host sopra la copia della configurazione, quindi claude --resume vede solo le sessioni di questo progetto e nient'altro. Attenzione: questo significa che un'iniezione di prompt memorizzata nella cronologia potrebbe ancora essere un rischio, se riprendi una sessione che contiene un'iniezione di prompt operativa, il raggio di esplosione diventa infinitamente più grande se esegui claude al di fuori di flar. Penso che la comodità superi il rischio, per qualsiasi progetto che abbia quel tipo di rischio, eseguilo sempre in flar.

• Codex CLI: Codex memorizza i trascritti in directory basate sulla data in ~/.codex/sessions/ e li indicizza nel state_5.sqlite globale; entrambi registrano il cwd di ogni thread, ma le directory su disco mescolano i progetti. flar assegna a ogni workspace una home Codex ombra in $XDG_STATE_HOME/flar/codex/<slug-progetto>/, con fallback a quando quella variabile non è impostata. Al primo utilizzo la popola solo con i file di trascritti corrispondenti, le righe SQLite e le voci della cronologia dei prompt. La home ombra viene poi montata come , quindi le nuove sessioni persistono senza esporre un altro progetto a .

~/.copilot/.flar/<slug-progetto>/

Al primo utilizzo, flar popola quella home ombra solo con le sessioni il cui cwd memorizzato corrisponde al workspace corrente, copiando sia le righe SQLite pertinenti che le directory session-state/ corrispondenti. Dopodiché, l'intera home ombra viene montata come ~/.copilot all'interno della sandbox, quindi copilot --continue può riprendere solo le sessioni di questo workspace, e le nuove sessioni persistono lì in sicurezza.

• Antigravity (agy): come per Copilot, le sessioni vengono "biforcate" al primo avvio in un progetto da flar, e non sono più condivise con agy eseguito al di fuori di flar.

agy non separa le conversazioni per progetto su disco. Ogni conversazione per ogni progetto vive in un unico store piatto sotto ~/.gemini/antigravity-cli/ (conversations/, brain/, implicit/), indicizzato solo da un UUID, con il workspace proprietario registrato all'interno di blob di conversazione opachi. Un indice di recency (cache/last_conversations.json) mappa ogni workspace alla sua conversazione più recente, che è ciò che agy --continue segue.

Montare quello store nella sandbox così com'è permetterebbe a un agy in sandbox di riprendere — tramite --continue, il selettore interattivo, o un esplicito --conversation <ID> — una conversazione appartenente a un progetto diverso, divulgando quanto vi è stato incollato. Per prevenire ciò, flar assegna a ogni workspace il proprio store con ambito:

~/.gemini/antigravity-cli/.flar/<slug-progetto>/

Questa directory viene montata su conversations/, brain/, implicit/, history.jsonl e cache/last_conversations.json all'interno della sandbox. Una sandbox aperta sul progetto A può quindi vedere solo le conversazioni del progetto A. Le nuove sessioni si accumulano nello store con ambito e sono ripristinabili all'esecuzione successiva.

La prima volta che flar esegue agy in un progetto, popola lo store con ambito di quel progetto dalla cronologia host esistente — ma solo con le conversazioni che agy stesso attribuisce a questo workspace (determinato da last_conversations.json e history.jsonl in testo semplice, mai analizzando i blob di conversazione). Dopo quel seed una tantum, lo store con ambito è indipendente: le nuove sessioni vivono solo nello store con ambito, e le modifiche lato host successive non vengono importate.

• Reasonix: Proprio come Claude Code. Reasonix mantiene la cronologia di ogni progetto nella propria sottodirectory, quindi può essere montato allo stesso modo di Claude Code, con la stessa avvertenza.

Conseguenze da tenere a mente:

• Copilot CLI: come per agy, la home ombra con ambito diventa un mondo separato per progetto dopo il seed iniziale. Le sessioni avviate con Copilot fuori da flar non vengono importate in flar in seguito, e le sessioni avviate dentro flar vengono salvate nella home ombra con ambito anziché nello store globale di Copilot dell'host.
• Le sessioni avviate con agy fuori da flar non sono visibili (a parte il seed iniziale) dentro flar, e viceversa. Questo è intenzionale — la cronologia di agy in flar è un mondo separato per progetto.
• Codex segue la stessa regola: dopo il seed una tantum, le cronologie di Codex avvolto e non avvolto sono indipendenti.
• Una conversazione che gli indici di agy non hanno mai attribuito al workspace corrente non viene inserita nel seed, per progettazione. Il default sicuro è trattenerla piuttosto che rischiare di esporre dati di un altro progetto.
• Le directory .flar/ di proprietà dell'agente sono escluse dalle copie di configurazione per compatibilità, e lo stato di proprietà di flar vive in (o ), al di fuori delle directory di configurazione gestite dall'agente.

Sicurezza di Rete e Porte Locali

In modalità di rete isolata, l'ambiente dell'agente non ha accesso diretto alle interfacce di rete dell'host.

• Accesso a Internet: Funziona automaticamente per richieste HTTP/HTTPS (come la connessione a LLM cloud come Anthropic o Gemini) utilizzando le variabili d'ambiente HTTP_PROXY e HTTPS_PROXY.
• Restrizioni Localhost: Le richieste a localhost o IP di loopback tramite il proxy sono bloccate.
• Esposizione di Servizi Locali: Per consentire all'agente di raggiungere un database locale o un LLM locale (ad es. Ollama su 127.0.0.1:11434), specifica la porta usando -allow-port 11434 o la configurazione allow_ports. Un forwarder di loopback sicuro collegherà 127.0.0.1:11434 all'interno della sandbox e proxyerà il traffico verso l'host.