When I run a coding agent locally, it can inherit the environment variables from my current shell. That might expose API keys, tokens, or credentials belonging to unrelated projects. How do you handle this in practice? Do you use a clean shell session, an environment allowlist, direnv, Docker, a VM, or a wrapper script? I'm mainly interested in practical setups for everyday development rather than enterprise infrastructure.
4 Answers
A per-project shell wrapper is another practical option. It can start the agent with an empty environment, set only an explicit list of harmless variables, and mount or provide secrets only for commands that genuinely require them. This makes the behavior repeatable instead of depending on whichever terminal session happened to launch the agent.
If the agent is not genuinely sandboxed, assume it can potentially inspect more than just the current project directory, including environment variables and files elsewhere on the machine. Docker or a VM provides stronger isolation, especially when sensitive credentials are present. At minimum, keep secret files outside the workspace and don’t pass unrelated credentials into the container.
I use a clean shell with no startup files, then load only the variables for the current project. Something like `env -i bash --noprofile --norc` works, and direnv can automatically apply the project-specific environment when entering the directory. This avoids relying on an allowlist that someone might forget to update.
That approach seems like a good balance for local work because it avoids adding containers when you only need to control inherited variables.
For development, I keep project-specific variables in a local .env file and avoid loading a large global profile into the agent’s shell. For production, we use a secrets service and mount credentials at runtime. It’s usually simpler and safer to give the agent only the variables that project needs instead of trying to filter a fully populated environment afterward.
That sounds manageable. Have you run into any workflow annoyances with keeping the development environment scoped that way?
Docker or a VM is probably the safest option, but it can feel heavy for routine coding. For day-to-day work, a clean shell plus project-scoped variables may be sufficient if the agent doesn’t need access to anything sensitive.