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

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.

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

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'

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.

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.