DEV Community: dw1

The most practical, fast, tiny command sandboxing for AI agents

dw1 — Tue, 17 Feb 2026 21:54:19 +0000

AI tooling is a chain of small, risky commands. I keep running model helpers, scraping CLIs, installer scripts, codegen steps, third-party formatters, and the occasional binary I only trust for five minutes. Most isolation options assume you want a whole environment. I usually do not. I just want one command to behave, not a whole damn platform.

Here I built sandboxer called sandboxec. It is a fast, small, single-binary wrapper for Linux that uses Landlock to enforce an allow list on filesystem and TCP access. No daemon or root, and no image build. It locks down one command and its children without dragging in a full runtime.

It starts like a normal CLI and applies policy right before execution. If it fails, it fails loud. That is what I want.

The point

sandboxec applies restrictions right before launching your command. The process and its children inherit them. You allow what you want and everything else is denied.

It can limit:

Filesystem read, write, execute
TCP bind and connect

This is not a container. It does not give you a new filesystem, cgroups, or resource quotas. It will not save you from kernel bugs or a local privileged attacker. It just narrows the blast radius for one command. That is the whole point.

That scope is the tradeoff. It stays focused and avoids the extra surface area that slows down bigger systems. It is fast (single binary, no warmup), clear (you see every path and port), cheap (no runtime lifecycle), and it fits the way AI pipelines actually run.

When I reach for it:

Running a third-party CLI against a local repo
Testing an install script before trusting it
Executing generated code in CI
Wrapping a build tool that only needs a few paths and outbound HTTPS
Running AI helpers that should not roam the host

If you need tenant isolation, stronger boundaries, or resource limits, use containers or a VM. That is a different problem.

The reason this can stay small is Landlock. It is the kernel feature doing the heavy lifting.

Landlock (briefly)

Landlock is a Linux security feature for unprivileged sandboxing. Unlike many LSMs, it lets a process restrict its own filesystem and network access, so you can cut down ambient rights without needing root. The LSM world has a bunch of flavors already (SELinux, AppArmor, Smack, TOMOYO), and Landlock is the one built for self-restricting apps. It is stackable, so it layers on top of whatever your system already does, instead of replacing it. That is why it is a great fit for a one-command wrapper: you can be strict where you need to be strict and leave everything else alone.

Getting started

Landlock support is required, so Linux kernel 5.13+ for filesystem rules. TCP rules need a newer Landlock ABI, usually kernel 6.7+.

If the kernel is missing a feature, you can run with --best-effort to degrade instead of failing.

Quick install:

go install go.dw1.io/sandboxec@v0.2.1

Go 1.24.0 or later is required. There are also prebuilt binaries on the release page.

Quick start:

Allow read+exec on /usr, then run id:

sandboxec --fs rx:/usr -- /usr/bin/id

Allow read+exec on system paths, read+write on the current repo and /tmp, then run a build:

sandboxec \
  --fs rx:/bin \
  --fs rx:/usr \
  --fs rw:$PWD \
  --fs rw:/tmp \
  --net c:443 \
  -- your-build-command

Outbound HTTPS only:

sandboxec --fs rx:/usr --net c:443 -- /usr/bin/curl https://example.com

Run a codegen step with a tight allow list, so a bad template cannot read your SSH keys:

sandboxec \
  --fs rx:/usr \
  --fs rw:$PWD \
  --fs rw:/tmp \
  --net c:443 \
  -- ./gen-code.sh

Rules

Filesystem rules are RIGHTS:PATH with rights like r, rx, rw, rwx.

Network rules are RIGHTS:PORT with rights like b (bind), c (connect), bc (bind+connect).

Rules are allow-list based. If a path is not listed, it is blocked. That means you often need to include runtime paths like /lib, /usr/lib, /etc, or the command will fail with permission errors.

This is the trade. You get control in exchange for being explicit, and most AI pipelines can live with that. If you hate being explicit, you will hate this.

sandboxec can read YAML config from sandboxec.yaml or sandboxec.yml. It checks $XDG_CONFIG_HOME/sandboxec, then ~/.config/sandboxec, then /etc/sandboxec.

Example:

abi: 6
best-effort: true
ignore-if-missing: true
restrict-scoped: false
unsafe-host-runtime: false
fs:
  - rx:/bin
  - rx:/usr
  - rx:/lib
  - rx:/usr/lib
  - rw:/tmp
net:
  - c:443
mode: run

CLI flags override config values. If you pass any --fs or --net flags, they replace the lists from the config.

MCP mode exposes a single exec tool. It runs commands with the same policy you define via flags or config. It is a clean fit for AI tools that want a locked down command runner without building a full sandbox system.

Example MCP config:

{
  "mcpServers": {
    "sandboxec": {
      "command": "/path/to/sandboxec",
      "args": [
        "--mode", "mcp",
        "--fs", "rx:/usr",
        "--fs", "rw:/tmp",
        "--fs", "rw:/path/to/your/workspace",
        "--net", "c:443"
      ]
    }
  }
}

Limits

Allow list only. Missing paths are hard failures.
--unsafe-host-runtime broadens access to runtime and shared libraries and can slow startup for tiny commands.
This is not a container and not a VM. Use the right tool for stronger isolation.

GitHub: https://github.com/dwisiswant0/sandboxec

If you want a low overhead guardrail for one command on the host, sandboxec does the job. It is boring and strict, and that is good. Issues and PRs welcome.

Introducing mmapfile: Unlock Fast File Access in Go with Memory-Mapped I/O

dw1 — Sun, 04 Jan 2026 17:00:00 +0000

Hey everyone, if you're a Go developer who's ever gotten frustrated with slow file ops, especially when dealing with big files or lots of reads and writes. Meet mmapfile, my little project that's basically a drop-in replacement for the standard *os.File -- but way faster. It uses memory-mapped I/O to skip a bunch of the usual overhead.

Let's chat about what it is, why it's cool, and how you can use it.

So, What is mmapfile?

mmapfile is a Go library that acts just like *os.File but under the hood, it maps files directly into your program's memory. Instead of calling the system for every little R/W operation, you get straight access to the file data. It's like having the file right there in RAM without actually loading it all up front.

It works on different systems, but if your platform doesn't support it, it just reads the whole file into memory as a fallback. See Platform Support.

The end result is a lot way faster file operations, especially for jumping around in files or reading A LOT.

Why?

I built this to be easy to swap in. Here are the highlights:

It's Basically Just *os.File: it implements all the interfaces you know and love:
- io.Reader, io.Writer, io.Seeker.
- io.ReaderAt, io.WriterAt, io.Closer.
- And more like io.ReaderFrom, io.WriterTo, io.StringWriter.
So, you can often just replace your os.Open calls with mmapfile.Open and be done.

I also write Semgrep rules to automatically detect *os.File usage and suggest mmapfile replacements. See Semgrep Rules.
Zero-Copy: the star of the show is the Bytes() method. It gives you a direct view into the file's memory. No copying, no extra memory use, just point and read.
Works Everywhere: Linux, macOS, Windows, even the weirder Unix variants. It handles the differences for you.
Safe for Multiple Threads: ReadAt and WriteAt are thread-safe, so you can have goroutines hammering away without issues.
No Memory Waste: most operations don't allocate anything on the heap (read: keeps your GC chill).

Getting Started

Get it with:

go get go.dw1.io/mmapfile

Quick example:

package main

import (
    "fmt"
    "log"

    "go.dw1.io/mmapfile"
)

func main() {
    f, err := mmapfile.Open("data.txt")
    if err != nil {
        log.Fatal(err)
    }
    defer f.Close()

    // read like normal
    buf := make([]byte, 100)
    n, err := f.Read(buf)
    if err != nil {
        log.Fatal(err)
    }

    fmt.Printf("Read %d bytes: %s\n", n, buf[:n])

    // or grab the whole thing directly
    data := f.Bytes()
    fmt.Printf("File contents: %s\n", data)
}

For creating files:

f, err := mmapfile.OpenFile("newfile.txt", os.O_RDWR|os.O_CREATE, 0644, 1024*1024) // 1MB file

The API (Nothing Fancy btw)

It supports most os.OpenFile flags, minus a couple we'll talk about later. Here's what you can do:

Method	What it does
Read([]byte)	Read some bytes, move the cursor
ReadAt([]byte, int64)	Read from a spot without moving the cursor
Write([]byte)	Write bytes, move the cursor
WriteAt([]byte, int64)	Write to a spot without moving the cursor
Seek(int64, int)	Jump to a position
ReadFrom(io.Reader)	Pull data from a reader
WriteTo(io.Writer)	Push data to a writer
Close()	Shut it down
Sync()	Save changes to disk
Stat()	Get file info
Name()	File name
Len()	File size
Bytes()	Direct memory access

The sweet spot is random access. Use ReadAt/WriteAt for the best speed.

See Go reference.

Performance

I ran some benchmarks against regular *os.File, and mmapfile just destroys it in most cases.

Reads

Tiny stuff (1KB): 50x faster.
Huge files (1GB): Still 3x faster.
Parallel reads: 10-12x faster (no matter the size).

Writes

Small (1KB): 51x faster.
Medium (100KB): 6x faster.
Big sequential (500MB+): A bit slower because the kernel's tricks win there.

Other Stuff

Seek: 29x faster.
WriteTo: 254x faster.
Overall: About 6x faster on average.

There is no system calls for most ops, just direct memory access. Fast, simple, no surprises.

When to Use It (and When Not To)

mmapfile shines in these spots:

Big files with random access: Like databases or parsing binary files.
Lots of reading: Configs, static data, lookup tables.
Memory-mapped DBs: Fixed-size stuff, logs that just append.
Shared memory between processes: Multiple programs reading the same file.
High-frequency I/O: Thousands of small ops per second.

Skip it for:

Streaming data: Like from networks or pipes.
Files that grow a lot: Needs fixed size.
Huge sequential writes: Kernel buffering beats user-space copies.
Tiny, rare files: Setup cost isn't worth it.

Gotchas and Limits

Nothing is perfect. Watch out for:

Fixed size: Can't grow files after opening. Set size when creating.
No truncate: To change size, close and reopen.
No append mode: os.O_APPEND is not there.
Cursor ops are slower: Stick to ReadAt/WriteAt.

and Bytes() gives you a slice that's only good until Close(). So if you mess with read-only files, you WILL crash.

Thread Safety

Built for concurrency:

ReadAt/WriteAt: Safe to call from multiple goroutines.
Read/Write/Seek: Share a cursor, so lock if concurrent.
Close: Don't call while others are running.

Real-World Uses

Perfect for:

DB engines: Quick jumps to data pages.
Log munching: Parsing giant log files.
Config loading: Fast parsing of big configs.
File caches: Persistent, memory-backed caches.
Science stuff: Working with binary datasets.

Wrapping Up

If you're hacking on Go apps with heavy file I/O, mmapfile could be your new best friend. The speedups for reads and random access are killer for modern apps.

But hey, it's not for everything. Think about your use case; do you need growing files? Streaming? If not, give it a shot.

This is pre-1.0, so things might change. Go check it out on GitHub, try it, and let me know what you think!