To understand what’s actually happening, could you please clarify a couple of things:
Did the agent actually call a tool like read_file on a path outside your workspace? Or did it just suggest or mention that path in the reply?
Does the path from option B (/front/mock/_config.js) actually exist on your file system inside another project’s folder?
Can you share the full chat so far, especially what you asked about the config file?
Also, the Request ID would help so we can check this on the backend. You can copy it from the chat menu (three dots in the top right of the chat) then Copy Request ID.
This will help us figure out whether the agent is really trying to access files outside the workspace, or if the model is hallucinating or pulling context from somewhere it shouldn’t.
It seems I understand what was happening. I provided that absolute path in my message. That file should be used as example, but cursor (AI) tried to add it into the project.
As the resolution I suppose there should be some guard which should always ask: I am trying to read out from project’s directory: allow, deny, always allow, always deny etc.
The “solved” mark was because we found the root cause. The agent followed the absolute path you shared in your message instead of reading files on its own.
About the guard you suggested, there’s already a setting called External File Protection. It adds a confirmation prompt when the agent tries to edit files outside the workspace. You can check if it’s enabled in Cursor Settings > Agents. You can also use a .cursorignore file in your project root to block agent access to specific paths.
That said, the current protection mainly covers edits and file creation. Reading files outside the workspace is less restricted. The team knows this could be better. I can’t share a timeline, but reports like yours help us prioritize.
That’s not the only instance in which an agent might do this. Just before, I merely asked a question about direnv and without me mentioning anything about .bashrc, it read it. Didn’t hallucinate either, since it accurately repeated my aliases back to me.
This is deeply unsettling. I get that when the LLM spawns a process, you can’t (without sandboxing) control what it accesses. But that’s not what happened here. The LLM clearly did that as a tool call that you have full control over. I would expect such calls to be refused by default if they’re outside of the workspace. If users enable full file system access in settings (or you prompt them), it’s a different matter.
Hey, I see the screenshot with the tool call. That’s a really awkward situation, especially when the agent decides on its own to read files like .bashrc.
How it works right now: by design, read_file has read access to the whole file system without approval. External File Protection only blocks writing and creating files outside the workspace, not reading. This is described in the agent security docs https://cursor.com/docs/agent/security:
Reading files and searching code don’t require approval.
What you can do today is add sensitive paths to .cursorignore at the root of your project:
~/.bashrc
~/.ssh/
~/.env
That will block the agent from reading those files.
How it works right now: by design, read_file has read access to the whole file system without approval. External File Protection only blocks writing and creating files outside the workspace, not reading. This is described in the agent security docs https://cursor.com/docs/agent/security:
I understood that as “within the workspace”. And so I think it should be mentioned that the whole file system is meant.
That will block the agent from reading those files.
Thanks for the suggestion but that doesn’t work.
And I have to say - given your seemingly lax stance on security, I can’t trust it to be a reliable long-term solution. I am migrating to exclusively working in dev containers instead.
Feedback on the docs noted. I agree the wording “Reading files and searching code don’t require approval” doesn’t make it clear this applies to the whole filesystem.
About .cursorignore, it should block read_file. Can you share what exactly didn’t work? What paths did you add, and where is the file located? .cursorignore needs to be in the project root. Example:
/home/user/.bashrc
/home/user/.ssh/**
If you used ~ instead of an absolute path, that could be the reason.
Dev containers as an isolation solution is a really solid option, especially if you have sensitive data on the host. No questions there.
Feedback on the docs noted. I agree the wording “Reading files and searching code don’t require approval” doesn’t make it clear this applies to the whole filesystem.
I’m glad to hear that you’re considering this!
If you used ~ instead of an absolute path, that could be the reason.
I tried both and simply asked “What aliases do I have declared in my .bashrc?”
LLMs were always able to access it.
Dev containers as an isolation solution is a really solid option, especially if you have sensitive data on the host. No questions there
Well, most people do. SSH keys at the least. An attacker might be able to publish malicious code while posing as the maintainer of the library/app. (Which I’m sure you’re aware of, I’m really just mentioning this in case of other people stumbling across this.)
About .cursorignore: a bug was fixed recently where .cursorignore wasn’t blocking file reads correctly. The fix shipped just a few days ago.
Can you check what version you’re on right now? Help > About. If you’re not on the latest, try updating, then test again using absolute paths in .cursorignore:
/home/user/.bashrc
/home/user/.ssh/**
Let me know if updating fixes it with .cursorignore.
