Set Environment Variables for Every Session with env in settings.json
If you need an environment variable available every time Claude Code runs a Bash command, the env key in settings.json is the cleanest way to set it. No shell profile changes required, and it works regardless of how Claude Code is launched.
{
"env": {
"NODE_ENV": "development",
"RAILS_ENV": "test",
"CLAUDE_CODE_ENABLE_TELEMETRY": "1",
"OTEL_METRICS_EXPORTER": "otlp"
}
}
Add this to ~/.claude/settings.json to apply the variables across all your projects, or to .claude/settings.json in a specific repo to scope them to that project only.
Common uses:
- Setting
NODE_ENVorRAILS_ENVso test commands work without extra flags - Enabling telemetry exporters for observability integrations
- Passing a custom npm registry or proxy URL to all Bash tool calls
The variables are applied to every session Claude Code starts. They supplement the environment Claude inherits from your shell rather than replacing it.
If you need a variable only in the current project and want to keep it out of version control, use .claude/settings.local.json instead (this file is gitignored by default):
{
"env": {
"DATABASE_URL": "postgres://localhost/myapp_dev"
}
}
Note that the env key in settings is separate from the ANTHROPIC_API_KEY and other variables used to configure Claude Code itself. Those belong directly in your shell environment.
The env key is the zero-friction way to make project environment variables available to every Bash tool call.
Log in to leave a comment.
When Claude writes error messages, button labels, validation text, or onboarding flows, it defaults to generic developer-speak. Add a "Users" section to your CLAUDE.md describing who your actual users are — their technical level, industry jargon, and what they care about — so Claude writes copy that makes sense to THEM, not to developers.
Use the --agent flag with custom markdown files in .claude/agents/ to launch purpose-built Claude sessions with restricted tools and scoped system prompts.
Every project has traps — the billing module that silently fails if you forget to queue the job, the legacy table with column names that don't match the model, the config value that must be set before tests run. Document these gotchas in your CLAUDE.md so Claude avoids the same mistakes your team spent days debugging.