ChatGPT and your local files: what leaves the Mac and what stays
Searching for ChatGPT and local files usually means one of two questions is being asked, and they have different answers. The first is mechanical: can this thing open a folder on this Mac and read what is in it. The second is about exposure: if it can, what is actually being sent somewhere else. Most of the guides that come up answer the first question with a plugin from 2023 and skip the second entirely.
The honest shape of it is that there are three routes from a model to a file on your disk, they behave differently, and the choice between them is a choice about blast radius rather than convenience.
Route one: the file goes to the model
Uploading is the route everyone starts with, and it is worth being precise about what it does. The file leaves the Mac in full. Not a summary of it, not the parts relevant to the question, the whole file. Once that is understood, most of the policy questions answer themselves.
The documented limits are generous. A conversation accepts files up to a hard cap of 512MB each, text and document files are capped at 2M tokens per file, spreadsheets and CSV files are limited to roughly 50MB depending on row size, and images to 20MB each. Throughput is the tighter constraint: 80 files every 3 hours on paid accounts, 3 file uploads per day on free accounts, with a total of 25GB per end user and 100GB per organisation. A custom GPT is a separate budget again, accepting up to 10 files for the lifetime of that GPT.
What makes uploading the wrong default is not the limits, it is the staleness. An uploaded file is a snapshot from the moment of upload. Every edit on disk makes the copy in the conversation wrong, and there is no signal when that happens. Anyone who has argued with a model about code it was looking at, while the file on disk had already been fixed, has met this. Uploading suits documents that are finished. It is a poor fit for anything still being worked on.
Route two: the model is given a door
The second route leaves the file where it is and gives the model an authorised way to ask for it. This is what connectors, and the Model Context Protocol servers built for the same purpose, exist to do.
The distinction from uploading matters. What crosses the network is the specific content requested during that exchange, not a full copy of everything the door can reach. The scope of the door, meaning which folder, which service, which permissions, is decided at setup time rather than per question.
The cost is setup and trust. Something has to be running, it has to be reachable, and whatever it is authorised to read, it can read on any turn of the conversation without asking again. A door pointed at a home directory is a door to browser profiles, SSH keys, and every unfinished document on the machine. A door pointed at one project folder is a door to one project folder. The difference takes ten seconds to configure and is the entire security story.
Route three: the model comes to the machine
The third route inverts the question. Instead of the file travelling to the model, a program runs on the Mac with an API connection outward. Codex and the other command line agents work this way, and the desktop application has moved in the same direction.
The current state of the Mac application is worth knowing before anyone downloads based on an old article. The desktop download page now offers a ChatGPT app that brings ChatGPT Work and Codex to the desktop, along with context from email, screenshots, files and what is on screen, and it lists ChatGPT Classic for Mac as a separate download further down the same page. So an instruction written a year ago may be describing an application that is still available but is no longer the one the download button gives you.
With a local agent, the exposure question changes shape. The agent reads files directly, so nothing is uploaded, but it sends whatever it decides to send as part of its reasoning: the file contents it read, the command output it captured, the error messages it hit. That is usually less material than a full upload and it is harder to predict, because the agent chooses.
What Work with Apps actually sends
The macOS application has a feature that sits between route one and route three, and its documentation is unusually specific about what crosses the network. Work with Apps lets ChatGPT read, and in editors edit, the content of an app you already have open. It needs version 1.2025.057 of ChatGPT for macOS or later, and the chat bar it works from opens with Option and Space.
The published rule is that ChatGPT includes the last 200 lines of open panes. Not the file, not the project, the visible pane. If text is selected, the selection becomes the focus and neighbouring text is included up to a truncation limit. The supported apps are named too: Terminal, iTerm, Warp and Prompt among terminals; Xcode, VS Code and its relatives including Cursor and Windsurf, and the JetBrains editors among code editors; Apple Notes, Notion, TextEdit and Quip among text editors. VS Code needs an extension installed to be readable at all, and the rest are read through the macOS Accessibility API, which means revoking Accessibility permission for ChatGPT in System Settings switches the feature off for that app.
Two consequences are worth holding on to. Anything included this way becomes part of the chat history stored in the account, and deleting a chat or the account removes it from OpenAI's systems within 30 days, with the usual exceptions for de-identified data and legal holds. And that content may be used to improve the models unless the account setting for improving the model is turned off, or the exchange happens in a Temporary Chat, which is not saved at all. A terminal pane is a plausible place for a token or a customer name to be sitting in the last 200 lines, so the pane worth checking is the one in front of you.
| Upload | Authorised connection | Local agent | |
|---|---|---|---|
| What crosses the network | The entire file | The content requested in that exchange | Whatever the agent reads or runs |
| Stays current with edits | No, it is a snapshot | Yes | Yes |
| Can write files back | No | Depends on the permissions granted | Yes, by design |
| Setup required | None | Configuration and something running | An installed tool and a scoped folder |
| Main risk | Sending more than intended, once | A door left wider than needed | Unreviewed changes to real files |
The question to settle before any of this
Only one decision in this area actually matters, and it is not which product to use. It is which directory the thing is allowed to see.
Anything pointed at a whole home directory is pointed at cached credentials, an .ssh folder, browser data, tax documents, and every draft of every unfinished thing. Anything pointed at one project folder is bounded, and a bounded mistake is recoverable. Making a folder per piece of work and opening the tool inside it costs nothing and removes most of the ways this goes wrong.
Two smaller habits complete the picture. Keep secrets out of the folders an agent works in, since an .env file sitting in a project root will be read the first time anything looks for configuration. And treat file writing as a separate grant from file reading, because a tool that can read a folder is doing research, while a tool that can write to it is doing work that needs review. In a repository, git status before accepting anything is the review, and outside a repository there is no equivalent, which is an argument for putting important folders under version control whether or not they contain code.
Three states a file can be in
A surprising share of the confusion in this area comes from a mismatch about which version of a file is being discussed. On a Mac at any moment, a file you are working on is in one of three states.
It can be saved to disk. It can be saved and also committed to version control. Or it can exist only as unsaved text in an editor window, which is the state files spend a lot of time in.
Anything reading the filesystem reads the saved version. An editor buffer with unsaved changes is not on disk, so it is invisible to an agent, to a connector, and to an upload. This is the mundane explanation for most cases of a model apparently ignoring an edit that is plainly visible on screen. The fix is to save before asking, and the habit worth building is to save and check git status before every instruction, so what the tool sees and what you see are the same thing.
The reverse case is worth knowing too. A tool that writes to a file while an editor holds an unsaved version of it sets up a collision, and whichever one saves last wins. Editors that reload changed files quietly will pick up the tool's version, and editors that do not will overwrite it on the next save. Working with one writer at a time avoids an afternoon of confusion.
Large PDFs, scans, and synced folders
Two practical obstacles come up often enough to plan for.
The first is scanned documents. A PDF made from a scanner or a photographed page holds images, not text. Uploading it sends every one of those images, which consumes the size budget quickly and produces worse answers than a text file a hundred times smaller. Extracting the text once on the Mac, keeping the result as a text file, and working from that is both cheaper and more accurate. It also means later questions do not require another upload against a daily limit.
The second is cloud synced folders. When a folder is managed by a syncing service with storage optimisation turned on, files that have not been opened recently can be evicted from the disk and left as placeholders until they are downloaded again. Finder hides this well, and a tool reading the folder directly may find a stub where the content was expected. If a folder is going to be the working directory for an agent, keep it downloaded locally rather than relying on files being fetched on demand.
The friction nobody mentions
Everything above assumes the hard part is the connection. In daily use it is not. The hard part is that the folder is in one window, the agent is in another, and the loop of checking what changed runs between them.
The loop is short and it repeats all day. Look at the files, ask for something, wait, look at what changed, check a preview, correct the instruction. Every step of that crosses an application boundary, and the crossing is where attention leaks. This is why a file manager with the terminal in the same window is not a cosmetic preference for this kind of work: the list of files and the agent working on them belong in the same field of view. The comparison with other file managers sets out where that boundary usually sits.
It also explains the awkwardness of the mobile case. An agent left running on a Mac at home will stop and ask a question, and the answer is one line. Getting to a Mac to type one line is the whole problem, which is the argument for reaching it from an iPhone or iPad instead of waiting until you are back at the desk.
What to change first
Stop uploading files you are still editing. Make a folder for the current piece of work, keep secrets out of it, put it under version control if it is not already, and point whichever tool you use at that folder and nothing above it. Then look at how many windows the check loop crosses, because that number is what sets the pace of the work, and Atriens is built to make it one.
Frequently asked questions
Can ChatGPT read files on my Mac directly?
Not on its own. A file has to be uploaded into the conversation, or reached through an authorised connection that you configure, or read by an agent that runs on the Mac itself. Those three routes send different amounts of material, and the local agent route is the only one that stays current as you edit.
What are the file upload limits?
Files in a conversation are capped at 512MB each, with text and document files limited to 2M tokens per file and spreadsheets to roughly 50MB. Images are limited to 20MB. Paid accounts can upload 80 files every 3 hours, free accounts 3 files per day, with a total cap of 25GB per user and 100GB per organisation.
Does the Mac desktop app see my files without being asked?
It sees what it is given access to, and access is granted per source. The current app combines Chat, Work and Codex and requires macOS 14 with Apple Silicon or an Intel processor. The safer configuration is the same regardless of product: scope any access to a single project folder rather than to a home directory.
Is uploading a file safer than letting an agent read the folder?
They fail in different directions. An upload sends one complete file once, which is easy to reason about and impossible to take back. A local agent sends only what it reads but chooses that itself, and it can also modify files. Scope the folder tightly and review changes, and the agent route exposes less in practice.
Why does an uploaded file give answers about code I already fixed?
Because the upload is a snapshot taken at the moment it was sent, and nothing tells the conversation that the file on disk has changed since. For anything under active editing, use a route that reads the file at the time of the question rather than one that carries an old copy.