flar

FLAR ist der Fast Light Agent Restrictor. Es läuft auf Steinen namens Gars.

Es ist ein einfaches, leichtgewichtiges CLI-Tool in Go, um Coding-Agent-CLIs (wie Claude Code, Antigravity, Codex, Copilot und Reasonix) sicher in isolierten Bubblewrap (bwrap)-Sandboxes auszuführen.

Der Zweck ist es, sofort und ohne komplizierte Konfiguration einen KI-Agenten zu bubblewrappen, sodass er nur Zugriff auf das Projekt hat, an dem Sie arbeiten. Dies schützt vor Prompt-Injection sowie vor Supply-Chain-Problemen in Bibliotheken, die der Agent möglicherweise ohne ausreichende Prüfung (oder einfach Pech) in Ihr Projekt zieht. Die einzigen zugänglichen sensiblen Informationen sind die eigenen Authentifizierungsdaten des Agenten und der Chatverlauf für das Projekt.

Die meisten Agenten haben eine „Sandbox“-Funktion, die jedoch recht porös ist und der Agent selbst den Umfang des Zugänglichen erweitern kann. Und natürlich unterliegen Supply-Chain-Schwachstellen nicht der Agenten-Sandbox. flar ist vollständig unempfindlich gegenüber dem Agenten und der Schadradius von Supply-Chain-Angriffen wird stark eingeschränkt.

Bubblewrap ist extrem gut getestet und wird aktiv gewartet. Es wird von Flatpack und vielen anderen Projekten für leichte Container verwendet. flar ist weit weniger gut getestet und wird von mir seit ein paar Tagen benutzt.

Funktionen

• Bubblewrap-Sandbox: Führt den Agenten in einem unprivilegierten User-Namespace mit einem sauberen Root-Verzeichnis (tmpfs) aus. Systempfade (/usr, /bin, /lib, /lib64 usw.) werden schreibgeschützt vom Host eingehängt, sodass Host-Pakete ohne Container-Image-Verwaltung sofort verfügbar sind.
• Strenge Dateisystemisolierung: Nur das Zielprojektverzeichnis wird lesend-schreibend gebindet. Der Rest des Host-Home-Verzeichnisses ist verborgen, wodurch SSH-Schlüssel, Shell-Konfigurationen und persönliche Dateien vor Prompt-Injection-Angriffen geschützt werden.
• Netzwerk-Sandboxing:
  • Isolierter Modus (Standard): Der Netzwerk-Namespace wird nicht geteilt. Der Internetzugang wird durch einen hostseitigen HTTP/HTTPS-Proxy getunnelt, der die DNS-Abfrage auf dem Host durchführt und Datenverkehr zu lokalen/Loopback-IP-Adressen herausfiltert.
  • Port-Weiterleitung: Lokale Dienste (z. B. Datenbanken, llama.cpp-Modelle) selektiv in die Sandbox freigeben, indem bestimmte Ports auf den localhost des Hosts gemappt werden.
  • Host-Modus: Möglichkeit, den Netzwerk-Namespace des Hosts für uneingeschränkten Zugriff zu teilen.
• Gefährliche Umgehungsoptionen: Injiziert automatisch Flags (wie --dangerously-skip-permissions für Claude/agy oder --dangerously-bypass-approvals-and-sandbox für Codex), sodass Agenten ohne Laufzeitgenehmigungsunterbrechungen ausgeführt werden. Kann mit deaktiviert werden.

Build und Installation

Abhängigkeiten

Stellen Sie sicher, dass bwrap (Bubblewrap) auf Ihrem Host-System installiert ist:

# Auf Fedora/RHEL
sudo dnf install bubblewrap

# Auf Debian/Ubuntu
sudo apt install bubblewrap

Kompilieren und Installieren

So bauen Sie flar aus dem Quellcode:

go build -o `flar` .

So installieren Sie es:

mv `flar` ~/.local/bin/

Verwendung

Führen Sie flar in Ihrem Projektordner aus oder geben Sie den Pfad an:

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

Flags

• -m: Agent festlegen, der ausgeführt werden soll (claude, codex, agy, copilot, reasonix). Standardmäßig wird anhand verfügbarer Host-Konfigurationen oder Umgebungsvariablen geprüft.
• -ask: Berechtigungen/Genehmigungen nicht überspringen (erzwingt, dass der Agent um Erlaubnis fragt).
• -network: Netzwerkmodus: isolated (Standard) oder host.
• -allow-port: Einen bestimmten lokalen TCP-Port (z. B. 8080, 11434) durch die isolierte Netzwerk-Sandbox zulassen. Kann mehrfach angegeben werden.
• -v: Ausführliche Protokollierung aktivieren.

Konfigurationsdatei (.flar.json)

Sie können Optionen pro Projekt in <project>/.flar.json oder global in ~/.config/flar/config.json konfigurieren:

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

Anmeldedaten

Da nur eine temporäre Kopie Ihrer Konfiguration eingehängt wird, werden Agenten authentifiziert unter Verwendung Ihrer bestehenden Host-Sitzung ausgeführt, ohne die Originale zu berühren. Die meisten Agenten speichern ihre Sitzung in Dateien, die flar direkt kopiert:

• Claude: ~/.claude/ (einschließlich .credentials.json) und ~/.claude.json, die Top-Level-Datei mit dem Onboarding-Status und der Kontoidentität. Beide sind erforderlich; mit nur den Anmeldedaten behandelt Claude die Sandbox als Neuinstallation und fordert zur Anmeldung auf.
• Codex / Copilot: ~/.codex/, ~/.copilot/ und die GitHub-CLI-Konfiguration.

Antigravity (agy)-Schlüsselbund

agy ist die Ausnahme: Es speichert sein Token nicht in einer Datei. Es verwahrt es im Betriebssystem-Schlüsselbund, das über die freedesktop Secret Service API über den D-Bus-Sitzungsbus gelesen wird. Die Sandbox hat keinen Sitzungsbus, daher schlägt eine naive Einrichtung mit authentication failed or timed out fehl.

flar behandelt dies speziell:

1. Auf dem Host extrahiert es nur das agy-Token (Schlüsselbundelement service=gemini, username=antigravity) mit secret-tool und schreibt es in eine 0600-Datei im temporären Konfigurationsverzeichnis.
2. Innerhalb der Sandbox führt es einen minimalen, eigenständigen Secret Service (flar --internal-secretsvc) auf einem privaten Unix-Socket aus, auf den mit DBUS_SESSION_BUS_ADDRESS verwiesen wird. Es stellt dieses einzelne Token und sonst nichts bereit.

Der Agent kann genau sein eigenes Token erreichen – nicht den Rest Ihres Schlüsselbunds (Browser-Passwörter, Geheimnisse anderer Apps usw.). Die Implementierung spricht das D-Bus-Drahtprotokoll direkt, benötigt also kein gnome-keyring oder dbus-daemon innerhalb der Sandbox.

Anforderungen und Einschränkungen:

• Die hostseitige Extraktion benötigt secret-tool (libsecret) auf dem Host. Wenn es fehlt oder das Token nicht gefunden wird, überspringt flar die Brücke und agy fällt auf die normale Anmeldeaufforderung zurück.
• Jeder authentifizierte Agent kann per Definition sein eigenes Token lesen; ein Prompt-Injection-Angriff könnte es exfiltrieren. Dies ist inhärent, wenn überhaupt authentifiziert ausgeführt wird. Die Schlüsselbundbrücke begrenzt die Gefährdung auf dieses eine Token anstatt auf Ihren gesamten Schlüsselbund.

Sitzungspersistenz und -fortsetzung

Da die Sandbox eine temporäre Kopie Ihrer Konfiguration einhängt, würde alles, was ein Agent dort schreibt, normalerweise beim Beenden verschwinden – einschließlich der gerade geführten Unterhaltung. flar bindet die Transkriptspeicherung jedes Agenten zurück auf den Host, sodass Sitzungen bestehen bleiben und später fortgesetzt werden können, während der Verlauf anderer Projekte aus der Sandbox ferngehalten wird.

• Claude: Transkripte leben in einem projektspezifischen Verzeichnis (~/.claude/projects/<project-slug>/). flar bindet nur das Verzeichnis des aktuellen Projekts vom Host über die kopierte Konfiguration ein, sodass claude --resume nur die Sitzungen dieses Projekts sieht. Achtung: Dies bedeutet, dass eine in der Historie gespeicherte Prompt-Injection immer noch ein Risiko darstellen könnte. Wenn Sie eine Sitzung fortsetzen, die eine funktionierende Prompt-Injection enthält, wird der Schadradius unendlich größer, wenn Sie claude außerhalb von flar ausführen. Ich denke, der Komfort überwiegt das Risiko; für Projekte mit einem solchen Risiko führen Sie es einfach immer in flar aus.

• Codex CLI: Codex speichert Transkripte unter datumsbasierten Verzeichnissen in ~/.codex/sessions/ und indiziert sie in der globalen state_5.sqlite; beide zeichnen das cwd jedes Threads auf, aber die Verzeichnisse auf der Festplatte vermischen Projekte. flar gibt jedem Arbeitsbereich ein Schatten-Codex-Home unter $XDG_STATE_HOME/flar/codex/<project-slug>/ und fällt auf zurück, wenn diese Variable nicht gesetzt ist. Bei der ersten Verwendung wird dieses Home nur mit übereinstimmenden Transkriptdateien, SQLite-Zeilen und Prompt-Historie-Einträgen befüllt. Das Schatten-Home wird dann als eingehängt, sodass neue Sitzungen bestehen bleiben, ohne dass ein anderes Projekt für freigelegt wird.

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

Bei der ersten Verwendung befüllt flar dieses Schatten-Home nur mit den Sitzungen, deren gespeichertes cwd mit dem aktuellen Arbeitsbereich übereinstimmt, und kopiert sowohl die relevanten SQLite-Zeilen als auch die passenden session-state/-Verzeichnisse. Danach wird das gesamte Schatten-Home als ~/.copilot innerhalb der Sandbox eingehängt, sodass copilot --continue nur die Sitzungen dieses Arbeitsbereichs fortsetzen kann und neue Sitzungen dort sicher gespeichert werden.

• Antigravity (agy): Wie bei Copilot werden Sitzungen bei der ersten Ausführung in einem Projekt durch flar abgespalten und nicht mehr mit agy außerhalb von flar geteilt.

agy trennt Unterhaltungen nicht projektbezogen auf der Festplatte. Jede Unterhaltung für jedes Projekt lebt in einem flachen Store unter ~/.gemini/antigravity-cli/ (conversations/, brain/, implicit/), nur durch eine UUID gekennzeichnet, wobei der zugehörige Arbeitsbereich innerhalb undurchsichtiger Unterhaltungsblobs aufgezeichnet wird. Ein Aktualitätsindex (cache/last_conversations.json) ordnet jedem Arbeitsbereich die letzte Unterhaltung zu, dem agy --continue folgt.

Das unveränderte Einhängen dieses Stores in die Sandbox würde es einem Sandbox-agy ermöglichen, über --continue, den interaktiven Picker oder eine explizite --conversation <ID> eine Unterhaltung fortzusetzen, die zu einem anderen Projekt gehört, und so den Inhalt preiszugeben. Um dies zu verhindern, gibt flar jedem Arbeitsbereich einen eigenen begrenzten Store:

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

Dieses Verzeichnis wird über conversations/, brain/, implicit/, history.jsonl und cache/last_conversations.json innerhalb der Sandbox eingehängt. Eine Sandbox, die für Projekt A geöffnet wird, kann daher immer nur Projekt A-Unterhaltungen sehen. Neue Sitzungen akkumulieren sich im begrenzten Store und sind beim nächsten Durchlauf fortsetzbar.

Beim ersten Mal, wenn flar agy in einem Projekt ausführt, befüllt es den begrenzten Store dieses Projekts aus Ihrer bestehenden Host-Historie – aber nur mit den Unterhaltungen, die agy selbst diesem Arbeitsbereich zuordnet (ermittelt aus dem Klartext last_conversations.json und history.jsonl, niemals durch Parsen der Unterhaltungsblobs). Nach dieser einmaligen Befüllung ist der begrenzte Store unabhängig: Neue Sitzungen leben nur im begrenzten Store, und spätere Änderungen auf der Host-Seite werden nicht eingezogen.

• Reasonix: Genau wie Claude Code. Reasonix behält den Verlauf jedes Projekts in einem eigenen Unterverzeichnis bei, sodass es auf die gleiche Weise wie Claude Code gebindet werden kann, mit der gleichen Einschränkung.

Zu beachtende Konsequenzen:

• Copilot CLI: Wie bei agy wird das begrenzte Schatten-Home nach der anfänglichen Befüllung zu einer separaten, projektbezogenen Welt. Sitzungen, die Sie mit Copilot außerhalb von flar starten, werden später nicht in flar gezogen, und Sitzungen, die Sie innerhalb von flar starten, werden in das begrenzte Schatten-Home zurückgeschrieben, nicht in den globalen Copilot-Store des Hosts.
• Sitzungen, die Sie mit agy außerhalb von flar starten, sind (abgesehen von der anfänglichen Befüllung) innerhalb von flar nicht sichtbar und umgekehrt. Dies ist beabsichtigt – flars agy-Historie ist eine separate, projektbezogene Welt.
• Codex folgt derselben Regel: Nach der einmaligen Befüllung sind die Historien von gewraptem und ungewraptem Codex unabhängig.
• Eine Unterhaltung, die agys eigene Indizes dem aktuellen Arbeitsbereich nie zugeordnet haben, wird nicht befüllt, by design. Der sichere Standard ist, sie zurückzuhalten, anstatt das Risiko einzugehen, Daten eines anderen Projekts preiszugeben.
• Agenteneigene .flar/-Verzeichnisse werden aus Kompatibilitätsgründen von Konfigurationskopien ausgeschlossen, und flar-eigener Zustand lebt unter $XDG_STATE_HOME/flar/ (oder ), außerhalb der von Agenten verwalteten Konfigurationsverzeichnisse.

Netzwerksicherheit und lokale Ports

Im isolierten Netzwerkmodus hat die Umgebung des Agenten keinen direkten Zugriff auf die Netzwerkschnittstellen des Hosts.

• Internetzugriff: Funktioniert automatisch für HTTP/HTTPS-Anfragen (z. B. zum Verbinden mit Cloud-LLMs wie Anthropic oder Gemini) unter Verwendung der Umgebungsvariablen HTTP_PROXY und HTTPS_PROXY.
• Localhost-Einschränkungen: Anfragen an localhost oder Loopback-IPs über den Proxy werden blockiert.
• Lokale Dienste freigeben: Damit der Agent eine lokale Datenbank oder ein lokales LLM (z. B. Ollama auf 127.0.0.1:11434) erreichen kann, geben Sie den Port mit -allow-port 11434 oder der allow_ports-Konfiguration an. Ein sicherer Loopback-Weiterleitungsdienst bindet 127.0.0.1:11434 innerhalb der Sandbox und leitet den Datenverkehr zum Host weiter.