# AI Hacker Daily — 2026-09-23 Two frontier models launched yesterday; Show HN answered with sandboxes.

Drop (Apache-2.0, Go, 210 stars, 367 commits, 1 contributor, created July 2025, v0.2.1 released August 24) is a rootless Linux sandbox built around the virtualenv workflow: drop init in a project creates an environment, drop run drops you into a shell in it, drop rm throws it away. The design choice that separates it from Docker is that it keeps your machine rather than replacing it. System directories are mounted from the host read-only, so every tool you already installed is there; each environment gets its own persistent home, /var and /tmp; and only the dotfiles you list in its TOML config come through, read-only. The README's own demo shows the point: ~/.bashrc is readable and not writable, and ~/.ssh does not exist. The project directory is writable except its .git subdirectory, which is read-only — which also means nothing inside the sandbox can plant a hook in .git/hooks for your unsandboxed git to execute later. It uses user, mount, PID, IPC, cgroup and network namespaces, drops all capabilities before exec, blocks access to services on localhost by default, and passes through only allowlisted environment variables. Since v0.2.0 on August 20 you can set runtime = "gvisor" (or drop run --runtime gvisor) so sandboxed processes stop issuing syscalls to the host kernel at all, with the two runtimes producing identical-looking sandboxes.

The Show HN (174 points, 59 comments) was the author's third submission, and the thread is where the threat model got stated precisely. One commenter pointed out that the read-only-everywhere, write-to-cwd default several agent harnesses ship is fine against a hallucinated rm -rf ~ and useless against a rogue npm package, which can still read your SSH key and send it somewhere. The author agreed and drew the same line: read-only protects against accidents, and hiding the key is the part that protects against malice. Asked why not a microVM, the author said a VM may become a third runtime, but the sandbox starts from your installed userland on purpose, because a stripped-down environment gets in the way of local work. A commenter who runs agents in VMs named the other side of that trade: Drop keeps an agent from deleting your files, but it does not keep the agent from uploading ones it can read.

Reach for it if you run coding agents on a Linux workstation and have been approving every command because the alternative was a container missing half your toolchain; it replaces the hand-assembled bwrap invocation you keep meaning to write. Delete the habit of running npm install for an unfamiliar repo in your real home directory. Tradeoffs: Linux only, terminal only (no GUI apps, no audio), and it cannot run inside a container or start one, so a docker compose dev stack is out; Ubuntu 24+ and Fedora need AppArmor or SELinux configuration before it will start; outbound internet is still open, so anything readable in the project directory can leave; and it is one person's isolation code — v0.1.8 in July was a security fix for capabilities not being dropped under --root, which is the right thing to disclose and a reminder that young sandboxes have young bugs.

Brig (Apache-2.0, Go, 128 stars, 11 forks, 223 commits, 8 contributors, created August 12, v0.2.0 released September 15) comes from NOFire AI, which built it for controlled autonomy in production remediation and open-sourced it for the case most readers have: a coding agent on auto-approve on your own laptop. brig run claude ~/code/demo boots a microVM, mounts that one project read-write at /work/demo, and starts Claude Code inside it. The guest boots with no credentials at all — the agent asks you to log in — and does not get your other host directories, your keychain or your SSH agent. Sessions are named (claude, claude@refactor), each with its own sandbox and its own guest home on the host, and brig rm throws the sandbox away without touching the project or that home. On macOS it drives hull, NOFire's own microVM runtime over Virtualization.framework; on Linux it uses urunc over KVM. The whole stack, microVMM included, is Apache-2.0.

Where Drop keeps your environment and adds walls, Brig starts from an empty guest and adds only what you name, and the README's section on the boundary is the most useful part of the repo. It says the project mount is your real files and the agent can change anything under it. It says that on the default network the agent reaches the internet, "so anything it can read it can also send." Egress policy is enforced only on hull's hvi backend, and Brig refuses a policy-bound run on any other backend rather than run it unenforced. Image verification defaults to warn, which reports an unverifiable image and boots it anyway; BRIG_VERIFY=require refuses instead. And while Brig itself counts nothing, the hull runtime on macOS sends a few telemetry events, with brig telemetry off to stop it.

Reach for it if you want the agent on a separate kernel and are willing to trade your installed toolchain for that; it replaces the hand-rolled Lima or UTM VM you set up once and never rebuilt. Delete the --dangerously-skip-permissions sessions you run directly on the host. Tradeoffs: macOS 15 on Apple silicon (14 with a flag and fewer profiles), or Linux with nerdctl, containerd and the urunc shim — no Intel Macs, no Windows; the README still describes the project as a prerelease in the 0.1.0-rc series a week after v0.2.0 shipped as a full release, so read docs/stability.md before scripting against it; and the default network plus warn-mode verification mean the out-of-box configuration is looser than the headline, by the README's own account.

Agent Chaperone (Apache-2.0, TypeScript, 20 stars, 52 commits, 2 contributors, created September 18, v0.3.1 released September 21, 703 npm downloads in its first four days) screens a coding agent's tool calls before they run and the results before the agent reads them. It works two ways: as an MCP proxy (agent-chaperone -- <the server you were going to run>, or agent-chaperone wrap <config>, which prints the edit and writes nothing until --write), and as PreToolUse/PostToolUse hooks for a client's built-in Bash, Edit, Write and WebFetch tools — the README's point being that a proxy never sees the shell, and the shell is where most of the damage lives. The pre-call screen asks whether a call is destructive, exfiltrates secrets, breaks a plain-English policy or is off-task for a task you declared; the post-result screen asks whether returned content is trying to instruct the agent. Deterministic allow and deny lists and secret patterns run first, and only what they do not settle goes to a model. It also digests the tool list each MCP server advertises and reports a rewritten description, an added tool or a vanished one.

The defaults are the reason to take it seriously. It installs in shadow mode, which logs every judgment including "(would have held it)" and blocks nothing, so you tune thresholds against your own traffic before switching to enforce. A held call is approved with a token keyed to that exact server, tool and argument digest, spent on use, so approving one write does not approve the next. And the "What it is not" section comes first: not a sandbox, not a replacement for the client's permission prompts, not a guarantee against adaptive attacks, and not local — screened content goes to the model backend, with secret-shaped strings redacted first. The measured results are published per set: AUC 0.976 on 1,394 InjecAgent tool responses, but also 8 false positives out of 68 benign items that merely discuss prompt injection at the default 0.5 threshold, 13 at 0.3.

Reach for it if you run agents with MCP servers or web access and want a log of what a screen would have stopped before deciding whether you want one; it replaces reading every tool result yourself or trusting none of them. Delete the blanket "deny all WebFetch" rule you added after the last injection writeup. Tradeoffs: the thresholds were chosen against TypeSafe's Jev, so real screening wants a TYPESAFE_API_KEY, and the OpenRouter fallback's probabilities are explicitly uncalibrated; roughly one in eight benign security discussions gets flagged at default settings, which will be noisy for anyone whose agents read security content; the 100-item hand-labeled tool-call set, where it scores best on calls, is the author's own; and every screened call sends its content to a third party.

Nimblegate (Go, 3 stars, 205 commits, created June 24, v0.4.7 released September 12, PolyForm Noncommercial) moves the pre-commit hook off the machine the agent controls. It runs as one Docker container on a separate host; you push to it over SSH on port 2222, it checks the push against the rules you enabled, and it forwards clean pushes to GitHub, GitLab or Gitea over HTTPS with the only upstream token, byte-for-byte unchanged — same SHA, same signature. The SSH user is locked to git-shell, so a dev key can move git data through the gate and do nothing else. The README's argument for why this is not redundant is specific: a pre-commit hook lives where the agent can --no-verify it, edit it, or never install it in a fresh worktree; branch protection gates the merge, by which time a leaked key is already an object in your upstream history; and CI's config lives in the repo the agent is editing. Of its 51 rules, the 18-rule core kit is on by default — hardcoded credentials, committed private keys, force-push to protected branches, --no-verify, rm -rf of protected paths, curl | sh, schema drift, non-idempotent migrations — and you can add regex rules from the dashboard with a preview of how many files each would have flagged.

Two design choices matter for agents specifically. A rejected push posts its findings as a sticky PR comment and a webhook, so the agent reads why and re-pushes, and the README makes the case that this loop only converges against a deterministic reviewer — pattern checks answer the same way every time and an AI reviewer does not. And its observe mode is deliberately silent to the pusher, so you can measure what an agent tries without it adapting to the gate, with the README equally blunt that observe mode is not a safety net. The "Where the responsibility lives" section says the rest: coverage is exactly the rules you enabled, and a gateway deployed on a box where an attacker gets a shell as the git user hands over the upstream token and bypasses the gate entirely.

Reach for it if agents push branches to repos you care about and you want credential leaks stopped before they are in the upstream's history rather than after; it replaces secret-scanning alerts you act on once the key is already public. Delete the plan to add one more pre-commit hook the agent can skip. Tradeoffs: PolyForm Noncommercial, perpetually, with no conversion date — any company use needs a commercial license, so this is source-available, not open source; it needs its own dedicated host to deliver its security claim, which is real infrastructure for a solo developer; and at 3 stars with the Show HN at 4 points, the "used in production since early 2026" line has no public users behind it yet, on a repo created in June.

all-your-agents (AGPL-3.0, TypeScript, 3 stars, 102 commits, 1 contributor, created September 17, v1.4.2 released today) lists every live Claude Code, Codex CLI, Grok Build and oh-my-pi session on a machine, sorts the ones waiting on you to the top, and lets you read any session's transcript with t. npx @markwylde/all-your-agents gives the full-screen view; --json --history gives every session, live or finished, for a script. It is also a library that emits session:create and status events, which is what the author actually built it for — an agent sidebar in their remote terminal app. The two rules they stated in the Show HN thread explain the design: never extend the harness in any way, not even with hooks or plugins, and never poll. Each harness gets a small provider that watches the files it already writes, such as ~/.claude/sessions/{pid}.json, and derives state from filesystem events.

It is in today's list because its README is candid about the gap every other tool here runs into. Permission approvals never reach disk, so an oh-my-pi session blocked on one reads running; Codex does not persist approval requests at all, so a Codex session waiting on you also reads running; claude -p writes no live index entry and shows up in history only. The "needs me" state an operator most wants is the one harnesses do not record. Each provider section also lists what it never opens — Codex's auth.json, Grok's auth.json and session-search database — which is the right thing to document for a tool that reads your agents' home directories. Asked in the thread why anyone would not just build this themselves, the author said: go for it, it was fun and a good way to learn how the harnesses work.

Reach for it if you run several agents at once and keep finding one that has been waiting on a question for forty minutes; it replaces cycling through terminal tabs to check. Delete the ps aux | grep claude alias. Tradeoffs: one contributor, three stars and six days old, with every harness's file format an undocumented internal that can change under it; AGPL-3.0, which matters if you embed the library in a product you distribute or serve; and macOS and Linux only, on Node 20 or later.

Also on the desk. Riftri (MIT, Rust, 16 stars, 3 contributors, v0.4.0 released today, from the assistant-ui team) makes Git worktrees for parallel agents copy-on-write, so ten checkouts of a large repo do not cost ten copies of it; it needs APFS, Btrfs, reflink XFS or ReFS, and it fails closed rather than falling back to a full copy when submodules, sparse checkout, custom filters or non-canonical LFS mean it cannot reproduce a checkout exactly. graf (Apache-2.0, Rust, 23 stars, created September 16) is a rewrite of the graphify code-graph tool with SQLite in place of NetworkX, claiming 1000x faster search on large repos and shipping a migration command from graphify; the speedup is the author's own benchmark.

Verification notes: star, fork, commit, contributor and release data are from the GitHub API on 2026-09-23; commit totals use the per_page=1 Link-header last-page trick. READMEs were pulled raw from each repo's default branch; Drop's filesystem layout is from droprun.sh/docs/sandbox-overview, and its gVisor date and the v0.1.8 capabilities fix are from its release notes. Brig's release history (rc18 on September 8, v0.2.0 on September 15) is from the releases API, against the README's "0.1.0-rc series" wording. Agent Chaperone's download count is from the npm downloads API (September 15–21; the package was first published September 18) and its benchmark figures are quoted from its README. Nimblegate's license terms are from the raw LICENSE file, which GitHub reports as NOASSERTION. HN points and thread quotes are from the Algolia API (items 49801329, 49802729, 49799938, 49789538, 49799267). Pipeline health: today's pool held 72 rows, down from 95 yesterday, against the ~280 the compose prompt assumes. Reddit returned zero rows again — 137 days since the last nonzero day on May 9. github:trending returned 11 rows across five feeds (all 3, go 2, rust 2, typescript 4, python 0), python empty for a second day.