Most guides answer the question "how do I give ChatGPT access to my files?". The opposite question gets less attention: once it has access, which files can it actually read and change, and how do you narrow that down?
I looked at how the common setups draw that line today. The short version: the line is almost always a folder, and inside that folder the assistant can usually do everything.
ChatGPT desktop and Codex
ChatGPT's desktop app and Codex share the same permission modes. The default, "Ask for approval", uses the workspace-write sandbox: the agent reads and edits files in the current workspace and asks before it goes beyond that boundary. "Full access" removes the boundary entirely. There is also a read-only sandbox mode, where the agent can inspect files but not edit them without approval.
If you need more than one folder, sandbox_workspace_write.writable_roots adds extra places it may modify.
One thing to notice: the documentation is precise about where the agent may write and run commands. It says much less about where it may read. If a file has to stay private, don't count on the write boundary to protect it.
Claude Desktop
In Claude's desktop app you attach workspace folders to a session. Inside an attached folder the agent can read, create and change any file your user account can reach.
Organizations can narrow this with a managed setting, allowedWorkspaceFolders. Each entry can be marked ro, which makes that folder read-only for the agent in Cowork. Anthropic's docs for managed deployments are honest about the limits: in Code sessions, read-only applies to Claude's file tools only, and shell commands don't enforce it. It is also an admin setting, so a single person on a personal laptop usually won't have it.
The MCP filesystem server
If you connect the reference filesystem MCP server, you give it a list of allowed directories. Everything inside them is open to its tools. The server has no read-only switch of its own. Issue #632 in modelcontextprotocol/servers has asked for one for a while. The workarounds people use are turning off the write tools in the client (a client setting, not a guarantee) or running the server in Docker with a read-only mount, which the OS actually enforces.
The pattern
Next to each other, these tools look the same:
- The unit of permission is a folder.
- Inside the folder, access is usually read and write.
- Read-only exists, but often only for admins, only in containers, or only for some tools.
- Nothing tells you afterwards which files were actually opened.
For a developer working in a repo, that is fine. The folder is the project and git is the undo button. For someone whose folder is "Documents", with invoices, contracts and family photos side by side, it is a lot coarser than it sounds.
What you can do today without extra software
- Make a dedicated folder for AI work. Copy files in, let the assistant work there, copy the results out. Boring, and it works with every tool above.
- Never attach your home folder or a whole drive. Attach the smallest folder that does the job.
- Have backups before any agent edits anything. Git for code, File History or Time Machine for the rest.
- Use read-only where it exists: the
read-onlysandbox in Codex,rofolders if your admin manages Claude, a read-only Docker mount for the MCP filesystem server. - Check what is attached before you start a session. Folders tend to stay attached long after the task that needed them.
Where Kobel fits
Disclosure: I build Kobel, so weigh this accordingly. It is a desktop app for Windows and macOS that sits between the AI app and your files as a local MCP server. You set permissions per file or per folder, with five levels: hidden, read only, edit a copy, edit with backup, and edit freely. New files in a folder take on its level, and every access shows up in an activity log.
It doesn't replace the steps above, and it can't do anything about data you have already shared. It makes the boundary finer than a folder, that's all.
Top comments (0)