Berry Wiki

Flar

Properties2
tagsai, sandboxing
aliasesFlar

6 min read

Flar

Summary

Flar, the Fast Light Agent Restrictor, runs coding-agent command-line tools inside a Bubblewrap process sandbox on Linux. It exposes one project, selected agent state, host tools, and proxied internet access without building a container image or booting a VM.

  • Repository: swelljoe/flar
  • Implementation: Go
  • License: Apache-2.0
  • Checked: 2026-07-14

Problem

Agent tools and downloaded dependencies can read secrets, damage unrelated files, or reach local services. Built-in agent permission systems may not cover child processes or compromised dependencies. Flar adds an external operating-system boundary while preserving the developer’s normal Linux tools.

How It Works

  • Clean view: Bubblewrap starts an unprivileged user namespace with a temporary root filesystem.
  • Host tools: System paths such as /usr, /bin, and /lib are mounted read-only.
  • Project scope: Only the selected project is mounted read-write.
  • Private home: Agent configuration is copied into a temporary home instead of exposing the host home.
  • Network namespace: The default mode removes direct network access and supplies a host-side HTTP/HTTPS proxy.
  • Scoped history: Agent sessions are copied or mounted into per-project stores to avoid exposing other projects’ conversations.
  • Autonomy: Agent approval checks are bypassed by default; -ask keeps them enabled.

Security Boundary

Flar relies on Linux user, mount, PID, and network namespaces provided through Bubblewrap. The agent shares the host kernel but sees a restricted filesystem and network view.

The intended boundary protects:

  • host home files such as SSH keys and shell configuration;
  • writable system paths;
  • unrelated project histories;
  • host loopback services unless a port is explicitly forwarded.

Important boundary limits:

  • Shared kernel: A Linux kernel or namespace escape can cross the sandbox.
  • Project writable: The agent can damage or leak the selected project.
  • Auth readable: Each authenticated agent can read its copied token or credential files.
  • Internet broad: The proxy permits outbound HTTP and HTTPS to public destinations; it is not a domain allow-list.
  • Host-network option: -network host removes network isolation.
  • Potential proxy gap: The checked proxy code blocks IPs for which Go reports IsLoopback(), but does not check private or link-local ranges. Despite the README’s broader “local/loopback” wording, RFC1918 LAN addresses may remain reachable through proxy CONNECT. This should be verified and treated as a possible security bug.

Platforms And Agents

  • Platform: Linux only; Bubblewrap is required.
  • Agents: Claude Code, Codex, GitHub Copilot CLI, Antigravity (agy), and Reasonix.
  • Default selection: Flar can choose an agent based on available host configuration or environment variables.
  • macOS and Windows: Not supported by Bubblewrap and not claimed by the project.

Setup

Install Bubblewrap through the Linux package manager, then build Flar from source:

go build -o flar .

Run flar from a project folder or provide a project path. Useful flags select the agent, keep approval prompts, switch network mode, allow a host port, or enable verbose logs. Project settings can live in .flar.json; global settings can live under ~/.config/flar/config.json.

No packaged release or installer was available at check time.

Network And Credentials

  • Default network: A separate network namespace prevents direct connections.
  • Internet: HTTP_PROXY and HTTPS_PROXY route traffic through a host-side proxy.
  • Local services: Specific loopback ports can be exposed with -allow-port.
  • Agent credentials: Claude, Codex, Copilot, and GitHub CLI state is copied to temporary configuration paths.
  • Antigravity token: Flar extracts only the relevant keyring item and serves it through a private in-sandbox Secret Service socket.
  • Token risk: An authenticated agent can read and exfiltrate its own token over allowed internet access.
  • Session state: Claude and Reasonix can use project-specific host history. Codex, Copilot, and Antigravity use scoped shadow stores after an initial import.

Strengths

  • Instant startup: No image download, build, or VM boot.
  • Normal toolchain: Read-only host system tools remain available.
  • Small visible scope: The project and agent-specific data replace broad home-directory access.
  • Supply-chain coverage: Child processes and build tools remain inside Bubblewrap.
  • Project-separated history: Other projects’ conversations are deliberately withheld.
  • Selective local access: Individual host ports can be forwarded without sharing the whole host network.
  • Credential minimization: The Antigravity bridge exposes one token instead of the whole keyring.

Limits

  • Very young: The author explicitly described Flar as far less tested than Bubblewrap.
  • Linux only: No macOS or Windows path.
  • No domain policy: Public internet access is broad, so readable data can be sent away.
  • Possible LAN exposure: The checked loopback filter may not block private-network addresses.
  • No package releases: Installation requires a local Go build.
  • Host dependencies: The sandbox inherits the host’s available tools and versions.
  • History split: Some agents’ sessions inside and outside Flar stop synchronizing after initial import.
  • Resume risk: A stored prompt injection can persist in conversation history and become more dangerous if resumed outside Flar.
  • No audit: No independent security review was found.

Activity And Maturity

Checked 2026-07-14:

  • Created: 2026-07-02.
  • Latest checked commit: e46462938a9b, dated 2026-07-13.
  • History: 28 commits.
  • Interest: 23 stars and 0 forks.
  • Releases: None published.
  • Assessment: Early personal tool with thoughtful credential and history handling, but not established security infrastructure.

Best Fit

Best for a Linux developer who wants a fast protective wrapper around local agents, uses the existing host toolchain, and mainly needs to hide unrelated home files and local services.

Use a VM instead for hostile code, stronger kernel separation, system-level package changes, cross-platform work, or strict destination allow-lists.

Comparison

  • Versus Clawk: Flar starts instantly and uses fewer resources. Clawk provides a separate kernel, disposable Linux system, and hostname allow-list.
  • Versus Docker: Flar reuses host tools without an image and exposes fewer moving parts. Both share the host kernel.
  • Versus agent-built-in sandboxes: Flar wraps the whole process tree, including downloaded tools, outside the agent’s control.
  • Versus Pi Landstrip: Both are process sandboxes. Flar supplies a Bubblewrap filesystem view and proxy; Pi Landstrip provides interactive path/domain grants across several operating systems.

HN Context

Flar’s author said they moved away from VMs because they wanted something lighter and faster. They described Bubblewrap as the balance between isolation and simplicity: the normal operating system is visible read-only, while sensitive directories are unreachable.

A reply proposed LXC plus eBPF for lighter container isolation and network safeguards. The author answered that full container systems were still too heavy and required tailoring to development needs. This highlights Flar’s central choice: reuse the host environment, but restrict its writable and sensitive parts.

Unknowns

  • Private-network blocking: Whether the current proxy intentionally allows RFC1918, link-local, and metadata-service addresses is undocumented.
  • Threat model: No formal security document defines protected and unprotected attacker capabilities.
  • Kernel requirements: Minimum kernel and user-namespace configuration are not stated.
  • Release process: No versioning, signed binaries, or package distribution is documented.
  • Test coverage: The repository has tests, but no independent penetration testing or audit was found.

Sources

Graph View