[SECURITY] allow ignoring files to prevent secrets being leaked from .env to LLM

Forgive me if I've missed it, but I couldn't see any mechanism in the code for ignoring files like .env which very often contain API secrets and other credentials and sensitive data.

The closest I could see was this hard-coded list:

https://github.com/sst/opencode/blob/67480e5a1c71a0b65467a724a7b7afa828f93168/packages/opencode/src/tool/ls.ts#L7-L19

If I'm right, that means that currently it's possible for security-critical data to be leaked to the LLM, which would be a pretty significant security concern. Other agentic coding environments have gone through the same pain, e.g. there are many threads such as this one in the Cursor forums. So it would be great if opencode got this right from early on.

I think it's fairly simple to solve: just support an .opencodeignore file at the top of the repo (and perhaps honour .gitignore by default too).

(On a related but tangential note, ideally everyone would standardise on .ai-ignore, .ai-rules etc. rather than every agent having its own set of config files, but that's a battle for another day ...)

See google-gemini/gemini-cli#2092 for a report of a similar issue there (although Gemini CLI does at least already respect .gitignore by default). Some approaches to the solution are also suggested in that issue.

Also anthropics/claude-code#79

our ls tool should be reworked to use rg which respects gitgnore - i'll do this

@thdxr

Thanks @thdxr this sounds like a great step in the right direction!

It reads my entire user directory without a hitch. Is this not a little worrisome? One thing is secrets like encryption, - and API keys, another thing entirely is personal medical documents and whatnot. Would it be possible to implement some sort of whitelist functionality where you explicitly state what folders/files are accessible?

It reads my entire user directory without a hitch. Is this not a little worrisome? One thing is secrets like encryption, - and API keys, another thing entirely is personal medical documents and whatnot. Would it be possible to implement some sort of whitelist functionality where you explicitly state what folders/files are accessible?

I created a separate issue for that here

In the meantime I'll just use it within a container.

A few improvements have been shipped in this area list of improvements:

Proper permissions system: you can make the llm have to ask you for permission before taking actions
agent is locked to cwd by default (can't use read or edit tools on files outside)
you can make plugins if you need even more control here is an example from docs:

export const EnvProtection = async ({ client, $ }) => {
  return {
    "tool.execute.before": async (input, output) => {
      if (input.tool === "read" && output.args.filePath.includes(".env")) {
        throw new Error("Do not read .env files")
      }
    }
  }
}

My $0.02:

If preventing opencode from reading sensitive files requires the user to go through any process more than an extremely simple configuration task (e.g. adding a file to .ai-ignore), then I don't think the feature can reasonably be considered as implemented. For example, while supporting more sophisticated control via plugins is awesome, if the user is required to write code, then it's an inherently insecure design by default.
I would strongly recommend making ignoring .env part of the default configuration. It's a very well-known industry-wide convention these days that this file typically contains secrets, so feeding those secrets to LLMs by default is really not at all good practice.

definitely fair point about .env I tend to agree w/ you there

agent is locked to cwd by default (can't use read or edit tools on files outside)

It can however, still use shell commands outside the CWD. Would it be feasible to just neuter opencode completely outside the CWD with options to open up its permissions if need be?

agent is locked to cwd by default (can't use read or edit tools on files outside)

It can however, still use shell commands outside the CWD. Would it be feasible to just neuter opencode completely outside the CWD with options to open up its permissions if need be?

While this is an important topic, and certainly requires attention, I think it belongs in a separate issue, because in the vast majority of cases .env will be inside the CWD.

@aspiers

@aspiers I will say the llm can't grep for this files but I think we may also want to add extra preventions by default in the read tool too. Thanks for pushing back on this a bit!

.env file being ignore fixed with ff1f4d6?

.env file being ignore fixed with ff1f4d6?

On version 0.15.13 just had grok-code-fast-1 unashamedly read and modify my .env without warning. This doesn't seem to have blocked reading or editing files named .env

I think this is a must feature, along with a more fine grained control on what tools and directories the agents can use.

We would appreciate .aiignore support!

OpenCode already supports .ignore files, but it's not blocking, for example, the read tool or grep tool from reading from those files.
You can check this plugin, https://github.com/lgladysz/opencode-ignore which extends some blocking functionalities for those tools except the bash tool, so, for example, Agent can read a file through the cat command. Gemini CLI is not blocking that, though.

Fell into this just now. #4308

Kinda concerning that a tool like OpenCode does not have these safeguards by default.

Fell into this just now. #4308

Kinda concerning that a tool like OpenCode does not have these safeguards by default.

I totally agree, but unfortunately even tools that have a deny setting sometimes find a way to circumvent this... (they act like humans 😆)

E.g., Claude Code in my case tried several times, and then found a way to overwrite the .env using the Bash tool and piping a new env var with > instead of >>.

Similar things happened to me with Gemini CLI and other agents. I found no tool so far that I would to some extent trust concerning "confident" or "secure" secret handling. With OpenCode I yesterday had to rotate a bunch of API keys (nothing bad to do) because it created an .env.example file and wanted to test it by copying its file with placeholder values to .env 😁 Nobody is to blame for this except me, but it's at least good to know that these things still happen (and that the plugin solution from the docs also does not handle this). I have also explicitly denied access in the agents file, and in the memories, but it's clear that I can just hope that this is being followed, and have to ask the bot to follow the rules from time to time (just like with a human coworker 🤭).

Probably using an MCP server for your vault is the best solution at the moment.

Or has anyone found a better solution for local development? Maybe the bots just want to educate us not to use dotenv files at all (but then there are products that still expect plain-text secrets in their MCP settings 😭🤣🤷).

I implemented this and it's working like a charm! I suspect the sandbox from anthropic would be a better approach but for now, opencode can't read or modify any file in my .codeignore. If this doesn't get implemented I could open a PR.

@betolink

@betolink What about Grep content in ignored files?

Also file should be named .ignore like in docs https://opencode.ai/docs/tools/#ignore-patterns

@rekram1-node

@rekram1-node isn't this fixed with 4c2e888 in v1.0.66?

Yeah I think this covers it

This is a good security feature, but is there a way to whitelist a .env file?

It is sometimes necessary for the agent to check the file in order to ensure that certain variables are being set properly.

@PhillipAWells

@PhillipAWells thats sounds like a very tricky request that won't meet strickt regulations because once the agent can read the file it means that the secrets inside were broadcasted to the model.

This was a short term solution, long term we want you to be able to define granular permissions for any tool and override defaults everywhere so everything can be exactly how you'd like it.

It would prolly look similar to bash tool but for read you'd be able to do something like:

read:
".env*": "allow"

But the default would be current behavior

feat: add C++ language support and hook tests (anomalyco#539)

fix(app): scope identities by workspace URL and ID (anomalyco#539)

Navigation Menu

Repository navigation

[SECURITY] allow ignoring files to prevent secrets being leaked from .env to LLM #539

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[SECURITY] allow ignoring files to prevent secrets being leaked from .env to LLM #539

Description

Activity

aspiers commented on Jun 29, 2025

aspiers commented on Jun 29, 2025

thdxr commented on Jun 29, 2025

aspiers commented on Jun 29, 2025

superDuperCyberTechno commented on Jul 11, 2025

SeanRoberts commented on Jul 12, 2025

rekram1-node commented on Aug 14, 2025

aspiers commented on Aug 14, 2025

rekram1-node commented on Aug 14, 2025

superDuperCyberTechno commented on Aug 15, 2025

aspiers commented on Aug 15, 2025

rekram1-node commented on Aug 15, 2025

fkukuck commented on Sep 25, 2025

mitchell-wallace commented on Oct 22, 2025

3 remaining items

betolink commented on Nov 11, 2025

JosXa commented on Nov 12, 2025

lgladysz commented on Nov 12, 2025

raymelon commented on Nov 13, 2025

redtux commented on Nov 14, 2025

betolink commented on Nov 14, 2025

lgladysz commented on Nov 14, 2025

lgladysz commented on Nov 16, 2025

rekram1-node commented on Nov 16, 2025

PhillipAWells commented on Nov 17, 2025

drorata commented on Nov 17, 2025

rekram1-node commented on Nov 17, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions