Your Coding Agent's Sandbox Just Handed Out Y

You trust the sandbox. That’s the whole point — you type /sandbox or toggle the isolation switch, and everything running inside can’t touch your real environment. Your AWS keys, your GitHub token, your production database URL — those live safely outside the wall.

A fix just landed in Gitlawb Zero that proves that trust was misplaced. The sandbox had a hole big enough to drive every one of your secrets through.

The Issue

Pull request #660 in Gitlawb Zero addresses a credential exposure bug: the sandbox environment was not scrubbing sensitive environment variables before passing them to executed code. Every AWS_* variable, every GITHUB_TOKEN, every DATABASE_URL, every API_KEY your shell had loaded was inherited verbatim by the sandbox process.

The PR description is blunt: “scrub sensitive credentials from sandbox environment.” Translation — any code you ran inside the sandbox, any extension you tested, any third-party plugin you loaded had unfettered access to every credential in your environment. The sandbox protected your filesystem and network, but left the front door wide open for credential theft.

Four commenters on the PR flagged additional categories of credentials that needed scrubbing — cloud provider tokens, package registry auth tokens, internal CA certificates. The fix is still being refined, which means even the initial scrub may miss some secrets. If you run Zero, treat PR #660 as “leak mostly closed,” not “leak closed.”

Are You Affected?

Check what credentials your shell has loaded right now:

# List sensitive environment variables
env | grep -iE '^(AWS_|GITHUB_|DATABASE_|API_KEY|SECRET|TOKEN|PASSWORD|DB_|PG|MONGODB|REDIS|NPM_TOKEN|NEXUS|JFROG)'

# Check if zero is scrubbing env
# Look for the sandbox env filter in zero's config
grep -r "sandbox.env" ~/.zero/ 2>/dev/null

You’re affected if:

You use Gitlawb Zero with sandbox mode
You have credentials in environment variables (most devs do)
You run untrusted extensions or third-party plugins
You haven’t audited what your sandbox inherits

How to Verify Your Sandbox Actually Isolates Secrets

The bug above is a specific instance of a general failure: sandboxes that filter the filesystem and network but pass env through untouched. You can test any agent’s sandbox in under a minute:

# 1. Load a canary secret into your shell
export CANARY_SECRET="sandbox-leak-test-$(date +%s)"

# 2. Launch your agent in sandbox mode and run:
#    env | grep CANARY_SECRET
#
# 3. If it prints the value, your sandbox leaks env.

This canary test is more honest than reading docs. Several agents claim isolation but still inherit process.env via the default child_process.spawn() options — exactly the mistake Zero made. Run the canary against every agent you use, including ones you trust. The result is usually surprising.

For the full list of what to check before letting any agent touch your machine, our coding agent security checklist for 2026 walks through sandbox, credential scoping, and network egress in one place. If you run agents from an AGENTS.md-driven workflow, our AGENTS.md complete guide explains how to pin exactly which commands and tools an agent is allowed to invoke — a second layer of defense when the sandbox itself is leaky.

The Fix

Update immediately: Pull the latest version of Zero containing the env scrub from PR #660.

Audit your environment: Before any sandbox session, clear sensitive variables manually:

# Create a "clean" shell profile for agent sessions
export ZERO_SAFE_ENV=true

# Or unset known sensitive vars before launching
unset AWS_SECRET_ACCESS_KEY
unset AWS_SESSION_TOKEN
unset GITHUB_TOKEN
unset DATABASE_URL

Check your other agents too: This bug isn’t unique to Zero. Test your agent’s sandbox:

# Run inside sandbox — if it shows your secrets, the sandbox leaks
env | grep -iE 'AWS|TOKEN|SECRET|KEY'

Credential Scoping That Actually Works

Patching the sandbox after the fact is defensive. The stronger move is to never load production credentials into the shell an agent inherits in the first place:

Use short-lived credentials. AWS IAM Identity Center / aws sts assume-role issues tokens that expire in minutes. A leaked token is a minor incident, not a breach.
Scope tokens to the task. A read-only GitHub token for a refactor agent beats a full admin token every time. Generate per-agent, per-repo tokens and revoke them when the task ends.
Keep a dedicated agent shell. Maintain a ~/.agent-env file with only PATH, HOME, LANG, and project-specific non-secret config. Source that, not your full login profile, before launching an agent.
Separate the secrets manager. Pull secrets from a vault (1Password CLI, AWS Secrets Manager, Doppler) at runtime inside code you control, rather than exporting them to the environment an agent can read.

Why It Happened

Zero’s sandbox implementation used Node.js child_process.spawn() with the default env option — which inherits process.env verbatim. The sandbox created filesystem isolation (via chroot-like mechanisms on Linux) and network isolation, but made no attempt to filter the environment block. Since Zero is typically launched from a shell that has loaded credentials for git, AWS CLI, npm, and other tooling, every one of those secrets was available to any extension or code running inside the sandbox.

The fix involves constructing a filtered environment object that passes through only non-sensitive variables — PATH, HOME, LANG, TERM, and similar — while stripping out known credential patterns. The challenge is that credential variable names vary wildly across platforms and tools, making a comprehensive blocklist difficult to maintain. A regex allowlist (pass only known-safe vars) is safer than a deny list (block known-secret vars), because the deny list can never predict the next tool’s naming convention.

FAQ

Q: Could a compromised extension exfiltrate my credentials? A: Yes. Any code running inside the sandbox could read process.env, serialize the entire environment block, and send it to an external server over the sandbox’s network connection (if network isolation wasn’t also configured).

Q: Do other coding agents have the same problem? A: Most agents that implement sandboxing inherit environment variables by default. Check your agent’s documentation for whether it explicitly scrubs env before spawning sandboxed processes. If it doesn’t mention env filtering, assume it leaks.

Q: How do I know if my credentials were already stolen? A: Rotate your credentials immediately — there’s no way to detect passive exfiltration. Generate new AWS keys, GitHub tokens, and database passwords. This is the safest response to any credential exposure vector. Cloud providers’ access logs can show where a key was used, but not whether it was copied — rotation is the only guaranteed reset.

Q: Should I just stop using sandboxes? A: No. A sandbox that leaks env is still far safer than no sandbox — it blocks filesystem and network escape, which covers the majority of real-world agent accidents. Treat env leakage as one layer of a defense-in-depth strategy, not a reason to abandon isolation. Combine the sandbox with scoped, short-lived credentials and you get most of the benefit back.

If you’re comparing agents on security posture rather than features, our best coding agents 2026 decision guide includes a sandboxing and credential-handling column you can filter by.

Built by Y Combinator alumni, aiFiesta gives you every major AI model in one chat for $12/mo. Compare answers side-by-side and pick the best one for your task.

Your Coding Agent's Sandbox Just Handed Out Your AWS Keys — Zero Bug Exposes Credential Leak