Repository navigation
.env files loaded without warning #2033
Description
When GH_TOKEN is set as an environment variable, it conflicts with gh CLI authentication when running commands through opencode's bash tool.
Opencode uses Bun runtime (via bun build --compile) which automatically loads .env files from the working directory. Variables like GH_TOKEN in .env get inherited by child processes, causing gh CLI authentication conflicts.
Should perhaps warn user when using .env vars that was perhaps not meant to be loaded by opencode.
Metadata
Metadata
Assignees
Labels
No labels
Activity
[-]GH_TOKEN environment variable conflicts with gh CLI authentication[/-][+].env files loaded without warning[/+]rekram1-node commentedon Aug 18, 2025
what kind of warning would you expect to see? I believe this is mentioned in docs but we could be more explicit perhaps?
pbjorklund commentedon Aug 18, 2025
Not sure, left the issue here as a fyi for the project and as a reference for if I google it again in the future. I did not expect opencode to be autoloading .env as default behavior.
I see it's documented under the
loginsection https://opencode.ai/docs/cli/#login andprovidershttps://opencode.ai/docs/providers/#amazon-bedrock / https://opencode.ai/docs/providers/#azure-openai, perhaps could be under config main heading?And while digging I found a solution to my problem via this plugin https://opencode.ai/docs/plugins/#env-protection
rekram1-node commentedon Aug 18, 2025
in regards to:
^ that plugin example was for the read tool specifically (that the agent invokes), but your issue seemed to be about the opencode binary loading all the env vars from .env, are you having a separate problem with the agent?
pbjorklund commentedon Aug 18, 2025
Yes I just noticed it didn't really do what I wanted.
It does that but still sources .env. Spoke to soon.
rekram1-node commentedon Aug 18, 2025
gotcha, so to address this best for you should I document this behavior better? or should we have some way of you overriding the variable or something?
Just wanna help address this best not sure what makes most sense. Curious to get your take
aspiers commentedon Aug 18, 2025
Is this different to #539? Sorry if I'm missing something.
rekram1-node commentedon Aug 18, 2025
yes @aspiers different because this is about the .env being loaded into process.env vs the other one is about LLM reading .env file
aspiers commentedon Aug 18, 2025
I see. IMHO opencode should never read
.env, except perhaps if there is some configuration option the user chooses to explicitly enable to allow it. My rationale is that.envis a widely accepted place for applications to put their secrets. So if opencode is automatically loading that intoprocess.env, it converts the whole of opencode into a huge attack surface through which those secrets could be leaked.If opencode wants to support configuration based on environment variables, I think it should load them from a separate file such as
.env.opencodeor.config/opencode/env. Separation of concerns is important for building a strong security model.aspiers commentedon Aug 18, 2025
Also at a glance it seems possible to override bun's default behaviour:
https://bun.com/docs/runtime/env#manually-specifying-env-files
nikhilmaddirala commentedon Aug 19, 2025
I haven't been working on any opencode projects that have api keys in env files, but I totally would not have expected this behavior if I hadn't read this thread. This is typically not the intended purpose of an env file in a project. Perhaps you could change this to read from '.opencode/.env' instead of '.env'.
rekram1-node commentedon Aug 19, 2025
I will mention this to team
th1m0 commentedon Sep 1, 2025
This is also causing other issues not just GH CLI issues. I have a development env (
.env) and a testing env (.env.testing) for a laravel project and it should automatically load the testing env when running tests. However when I run the tests in opencode (not even having to use the agent I can just run it using the! <cmd>. it will always force use the development env (because that is in.env?). This means when the agent is running my tests it will just clear my local db always... running this outside of opencode it does just work normally.dwarfi09 commentedon Sep 6, 2025
I haven't configured openrouter for opencode.
Nevertheless, I can access the openrouter models in opencode in some projects. It took me some time to realize that this is because I stored openrouter keys in the projects' .env files (OPENROUTER_API_KEY). However, the keys are stored for the projects (applications), not for opencode...
chnln commentedon Sep 8, 2025
same for my openai api ...
luisrudge commentedon Sep 16, 2025
I got hit by this today when I signed out of my personal Anthropic account, signed into
OpenCode Zen for testing, then opened OpenCode in my employer's project folder containing
a .env file with Anthropic API keys.
OpenCode defaulted to using an anthropic/xxxx model
and silently consumed my employer's API credits from the .env file without any warning. I only noticed when the account balance hit $0. This automatic .env loading creates a
serious risk of unknowingly burning through unintended API credits.
IMO this is pretty serious and shouldn't be taken this lightly. Reading .env file by default makes no sense for a tool like this cc @thdxr @rekram1-node
rekram1-node commentedon Sep 17, 2025
Sorry to hear that luis :/ I will bring this up to Dax
thdxr commentedon Sep 17, 2025
damn sorry about this - this is default behavior in bun, we just pushed a change to disable it
aspiers commentedon Sep 17, 2025
Hey @thdxr thanks a lot, that sounds great!
Btw it would be really helpful in future if you could reference the specific commit or PR that fixes the issue so that interested parties can learn the nature of the fix. As you probably already know, if the relevant commit or PR contains "Fixes #2033" then GitHub takes care of this automatically, which is a really handy time saver for establishing bi-directional links.
rekram1-node commentedon Sep 17, 2025
Here is commit: ff1f4d6