Copilot CLI attempts to read .env

Context: I am working on config.py and asked if what oAuth creds we are using on FastAPI swagger. Then it asked if it can grep to my .env

I dis not give it permission to run the grep command. I got curious what it will do when explicitly asked to check so I prompted it to look to my .env to test. Then this time, it just try to use config.py to answer my question.

What would you expect the behavior to be here? It sounds like copilot appropriately asked you for permission here and gave you the chance to reject reading that file. Is something else awry?

Indeed, the tool calling permission is working. The thing that sets alarm to me is that in tried to read .env file unprompted. The least expectation,at least for me, is that cli agents and/or agentic tools should not read .env under any circumstance as a global safety net, maybe even coaxing and explicit request may or may not read it (depends on the tool philosophy).

What happen here is that it is nowhere on the previous prompt I even mention the .env file but it then decided to read it (ofc asking for permission as any other grep ) . Then I asked it explicitly to read it, then this time it did not tried to read it but instead it figured out it can do the same thing just by reading config.py, which is true. This suggests, that somewhere on the System Instruction or tool calling instruction, there is already restriction to not use .env by default.

I have been using Copilot Chat in VS Studio and Claude Code as well. Both of which have not tried or prompted me to read .env (yet :)). So my gut feel is that this is something worth raising an issue for, to check how the copilot cli treats potentially sensitive files

I might be completely wrong on my assumptions or this might not reflect the philosophy this tool is aiming for.

It's a bit tricky because the agent did act in a way that was firmly aligned with your very specific request from what I can tell. It used a shell command to only seek out the single value as requested without passing the entire .env file through the agents context window.

I would consider this an issue if the entire .env file was passed into the agents context window, but in this instance it appears the agent was very targeted and built the right shell commands to extract just the information you requested by correctly identifying that the .env file has the answer you are specifically looking for. This is a big improvement from older models that would default to injecting the .env file into the context window exposing all secrets to an outside service.

Would love thoughts or suggestions on how we could improve the experience. We are considering options such as highlighting more dangerous commands like rm and reading the .env file when requested so you can more readily identify these approval prompts.

You are correct. Thanks for pointing out that it did grep a "non sensitive" field and asked for a permission.

Since its really hard to give a guard rail for agents, your suggested idea to Highlight or make it very obvious for user on permission asking for actions that are destructive and sensitive in nature!🤯😍

Appreciate the feedback @TheRebootr. Will close for now since we agreed the behavior as expected. We'll continue working internally to figure out a better long term solution for calling out dangerous or sensitive commends. You'll probably see an improvement show up early next year.