.env files loaded without warning

[pbjorklund]

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.

[rekram1-node]

what kind of warning would you expect to see? I believe this is mentioned in docs but we could be more explicit perhaps?

[pbjorklund]

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 login section https://opencode.ai/docs/cli/#login and providers https://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]

in regards to:

And while digging I found a solution to my problem via this plugin

^ 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]

Yes I just noticed it didn't really do what I wanted.

It does that but still sources .env. Spoke to soon.

[rekram1-node]

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]

Is this different to #539? Sorry if I'm missing something.

[rekram1-node]

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]

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 .env is a widely accepted place for applications to put their secrets. So if opencode is automatically loading that into process.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.opencode or .config/opencode/env. Separation of concerns is important for building a strong security model.

[aspiers]

Also at a glance it seems possible to override bun's default behaviour:

https://bun.com/docs/runtime/env#manually-specifying-env-files

[nikhilmaddirala]

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]

I will mention this to team

[th1m0]

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.