# GAL: a single-binary AI agent runtime that is kernel-sandboxed by default > Source: > Published: 2026-10-26 14:08:14+00:00 Most "AI agent" projects you can try today want you to `pip install` a tree of dependencies, hand over an API key, and then trust the thing with `rm -rf`-level access to your shell. That is a lot of trust to give a model that is, famously, confidently wrong sometimes. **GAL** (General Agent Loop & Executor) takes a different bet: an LLM agent you can actually let loose on your own machine, because it ships as **one binary** and runs **inside a real OS sandbox by default**. No Python. No Node. No Docker. Download a file, run it. GAL is a self-contained agent runtime with three front ends built into the same binary family: `gal`` galw``gal serve` It runs on **Linux, macOS, and Windows**, and it is *local-first*: your files, your machine, your tokens. Zero install means there is nothing to break and nothing to keep in sync. The reason most people won't let an agent touch their real machine is that one bad turn can cost hours. GAL's answer is a kernel-level sandbox that behaves the same way on every OS: Inside your project the agent gets full productivity. Outside it — corrupting the machine, exfiltrating secrets — it is blocked by the kernel, not by a polite prompt. And when it genuinely needs elevated access? You type ``` /sudo restart the nginx service and tail the log ``` which grants **exactly one turn** of unrestricted access and then automatically snaps back to the sandbox. No permanent "yes, allow everything" checkbox. Model-driven memory means the agent decides what to summarize and what to keep, so you can run tens of thousands of agent rounds in a single session with the current turn always protected. No more "sorry, I forgot what we were doing 40 steps ago." `SKILL.md` plus scripts into a folder; the LLM discovers it and turns the scripts into tools. So the runtime stays small; you grow its capability with plain files and standard MCP servers. Grab the archive for your platform from the [download page](https://agent-home.ai/download.html) or the [GitHub releases](https://github.com/gal-agent/gal-release/releases): | Platform | CLI ( `gal` ) | GUI ( `galw` ) | |---|---|---| | Linux amd64 | `gal-linux-amd64.tar.gz` | `galw-linux-amd64.tar.gz` | | macOS Intel | `gal-darwin-amd64.tar.gz` | `galw-darwin-amd64.zip` | | macOS Apple Silicon | `gal-darwin-arm64.tar.gz` | `galw-darwin-arm64.zip` | | Windows amd64 | `gal-windows-amd64.zip` | `galw-windows-amd64.zip` | **Linux / macOS:** ``` tar xzf gal-linux-amd64.tar.gz # or gal-darwin-arm64.tar.gz, etc. chmod +x gal ./gal init && ./gal chat ``` **Windows:** unzip `gal-windows-amd64.zip`, double-click `gal.exe` (CLI) or `galw.exe` (GUI). **Verify** what you downloaded: ``` sha256sum -c checksums.txt --ignore-missing ``` Because the hard part of putting an agent on a real machine was never the model call — it's the **blast radius**. GAL's wager is that capability is becoming cheap, and the thing worth engineering carefully is the boundary: what the agent may touch, when it must ask, and how it gets put back in its box afterwards. A single binary with a kernel sandbox is a much smaller thing to trust than a dependency tree with `sudo`. If you try it, I'd genuinely like to hear where it fights you — that's the useful feedback.