When I run a coding agent locally, it can inherit the environment variables from the shell that launched it. That could expose API keys or credentials belonging to unrelated projects. How do you handle this in practice? Do you use a clean shell session, project-specific environment files, direnv, Docker, a virtual machine, a wrapper script, or another isolation method? I'm mainly interested in practical setups for everyday development rather than enterprise platforms.
4 Answers
For production, credentials should come from a secrets service and be mounted or injected only at runtime. For local development, a project-scoped `.env` file is more convenient, as long as it is excluded from version control and the agent is started from a shell that never loaded global credentials.
The simplest approach is to avoid giving the agent a polluted shell in the first place. Start it with an empty environment, such as `env -i bash --noprofile --norc`, then load only the variables required by that project. Using direnv or a project-specific `.env` file makes this manageable. I prefer that over an allowlist because allowlists can become stale and create a false sense of security.
For stronger isolation, run the agent inside Docker or a virtual machine and mount only the project directory and the specific secrets it needs. Sensitive files can be left outside the container or replaced with empty mounts. It’s more setup than a clean shell, but it’s worthwhile when the agent has broad filesystem or command execution access.
Docker can feel excessive for routine edits, but it’s probably the safer default when the agent is untrusted or the machine contains valuable credentials.
A project directory by itself isn’t necessarily a security boundary. Some coding agents can still access the broader filesystem or inherited process environment, so changing directories won’t reliably hide secrets. If the tool doesn’t provide real sandboxing, use a clean environment plus container or VM isolation for sensitive work.
That seems like a good balance for normal development. I’d still want a container or VM for agents that can inspect the entire filesystem, since limiting environment variables alone doesn’t protect unrelated files.