Sandboxing Untrusted Tools In Dev Workflows Failure Patterns: practical systems guide

# Sandboxing Untrusted Tools In Dev Workflows: Failure Patterns

When you let an AI agent or third-party script touch your repository, you're betting on isolation you probably haven't tested. The classic failure mode isn't a dramatic breach—it's the Tuesday afternoon when your CI starts emitting AWS credentials in build logs because someone's linter plugin decided to `console.log(process.env)`, or the Friday deploy that hangs because a formatter wrote a 4GB temp file to `/tmp` and your container ran out of disk.

Sandboxing untrusted tools sounds straightforward until you enumerate what "untrusted" actually includes: not just random npm packages, but also your own shell scripts invoked by agents, language servers spawned by editors, pre-commit hooks inherited from a template repository three teams ago. Each one represents a trust boundary you've likely never drawn on a diagram.

The filesystem escape via config file traversal

Most sandboxes start by restricting filesystem access to a working directory. The immediate failure: nearly every development tool reads config from parent directories. ESLint walks upward looking for `.eslintrc.js`, Prettier checks seven levels up for `prettier.config.mjs`, and Python's `setup.py` will happily import from `../shared_utils`.

A sandbox that just `chroot`s or bind-mounts a subdirectory breaks these tools. The workaround—allowing read access to parent directories—opens a hole: now your untrusted script can parse your root `.npmrc` with registry credentials, or traverse up to `~/.aws/config`.

The pattern that survives contact with real toolchains: explicitly copy config files into the sandbox root before execution, rewriting relative paths as you go. If the tool expects `../../tsconfig.base.json`, copy it to `./tsconfig.base.json` and patch the reference. This works for declarative configs (JSON, YAML) but fails for executable configs that dynamically import sibling modules. At that point you're choosing between "tool doesn't work" and "sandbox isn't real."

Network access: the binary choice that's actually ternary

You can run tools with network fully enabled, fully disabled, or with a filtering proxy. The filtering proxy sounds sophisticated until you implement it: you need to allowlist registries (`registry.npmjs.org`, `pypi.org`, `crates.io`), CDNs for common tooling, and then the long tail of language-specific mirrors and corporate proxies.

The failure mode that surprises people: DNS. Even with network disabled, many tools attempt DNS lookups that block for 5+ seconds on timeout. `node` itself checks for proxy autoconfiguration, `git` tries to resolve remote URLs even for local operations, and language servers ping update endpoints. You're not actually saving time or improving isolation by blocking network—you're just making everything slower and introducing non-deterministic timeouts.

A pragmatic middle ground: allow outbound network but firewall local network ranges (`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`, `127.0.0.0/8`, and IPv6 equivalents). This prevents SSRF-style attacks against your internal services while letting tools fetch public dependencies. You still need egress logging so you can detect when something starts phoning home to `evil.example.com`, but at least `npm install` completes.

Resource limits that break before malicious code does

Set a memory limit too low and legitimate builds fail; set it too high and you're not really sandboxing. The pathological case: a tool that leaks memory slowly. It runs fine for small projects, passes your test suite, then OOMs on a 50k-line monorepo three hours into a CI job.

CPU limits have the opposite problem. Most sandbox systems use CPU time (user+system), but build tools care about wall time. AFormatter that normally takes 2 seconds can take 40 seconds when CPU-throttled, which triggers timeouts in your wrapper script. Now you're debugging whether the timeout is too aggressive or the tool is actually hanging.

Disk quotas fail on filesystem cache patterns. Modern package managers (pnpm, Cargo, Go modules) maintain global caches that multiple projects share. If your sandbox gives each invocation its own view of the filesystem, every run re-downloads dependencies. If you share the cache across sandboxes, one malicious tool can poison it for everyone else by writing corrupt artifacts.

In practice: set memory limits at 2-4x the expected steady-state usage, skip CPU throttling unless you're defending against crypto miners, and treat disk quotas as "detect runaway growth" rather than "prevent writes." Real isolation comes from making the cache read-only and copying on write only what each tool legitimately modifies.

The agent-specific failure: transitive tool invocation

When an AI agent generates a fix, it doesn't just write code—it runs formatters, linters, test suites, and then potentially more tools discovered in `package.json` scripts. Your sandbox needs to be recursively safe: if the agent invokes `npm run lint`, and that script runs `eslint --fix`, and eslint loads a plugin that shells out to `prettier`, you need to ensure that entire chain stays contained.

The naive approach is to sandbox the initial tool invocation. This breaks immediately because `npm run` spawns subprocesses that escape your sandbox boundary. The heavyweight approach is nested sandboxes (container-in-container), which works but makes debugging failures nearly impossible—stack traces disappear, exit codes get mangled, and you can't easily attach a debugger.

Goatfied's agent loop sidesteps some of this by running tools in explicit phases: plan (read-only), edit (write to temp), validate (compile/lint/test in a gated environment where failures just trigger retry). Each phase runs in its own execution context with appropriate permissions. The validate phase particularly benefits from full sandboxing because it's running tests—which by definition might be malicious—but failures there don't corrupt the working tree. You get a clean edit/validate boundary instead of trying to sandbox arbitrary recursive tool invocations.

Logging and audit without destroying performance

If you log every syscall, you can't move. Strace adds 10-100x overhead. Instead, log at semantic boundaries: tool invocation (what binary, what args), network connections attempted (even if blocked), and file writes outside the expected output directory. This gives you an audit trail you can review when something suspicious happens, without making normal builds glacial.

The key insight: you're not trying to prevent every possible attack at runtime. You're trying to detect anomalies and constrain blast radius. If a tool writes 500MB to `/tmp` instead of the usual 5MB, log it. If it tries to connect to an IP you've never seen before, log it. Then have a human review those logs before they turn into incidents.

Related reading

• [The Goatfied agent loop: how we ship code that actually compiles first try](/blog/goatfied-agent-loop-compiles-first-try)
• [Goatfied vs Cursor vs GitHub Copilot: a benchmark across 50 real PR tasks](/blog/goatfied-vs-cursor-vs-github-copilot-benchmark-50-pr-tasks)