Codex Local vs Cloud: What Actually Happens to Your Files and Code
Codex can run against local files on your machine or in a cloud sandbox. Here's what that distinction actually means for how you work.
What’s the difference between local and cloud in Codex?
Local means the files Codex is reading and writing only exist on the machine you’re currently using. Cloud means those files or outputs are reachable from somewhere other than that one machine. This sounds basic, but it matters constantly when you’re working with an AI coding agent, because whether something is local or cloud determines who can see it, where it persists, and whether you can pick up the same work from a different device.
TL;DR
- Local files in Codex live only on the machine you’re working from, the same way an unsaved Word document is stuck on one laptop until you move it.
- A project opened in Codex is really just a folder on disk that the agent reads from and writes to, nothing more mystical than a file path.
- Codex can spin up outputs like local web previews using a localhost address (something like
127.0.0.1with a port number), which only renders on the machine that generated it. - Anything synced through a service like OneDrive or Google Drive effectively becomes cloud-accessible, even if it started as a local file.
- The local versus cloud distinction is separate from, but related to, how an agents.md file routes the agent to the right files inside a large project.
- Understanding this distinction helps explain why a Codex-generated preview link can’t just be emailed to a teammate and opened on their own computer.
How does Codex treat a “project” on your machine?
A Codex project is a collection of folders and files, the same structure you’d see in any file explorer. When someone has a project open in Codex, they’re pointing the agent at a specific file path on disk. That path can contain anything: credentials, prior chat history, business documents, code, whatever the user has organized into that directory.
Because Codex reads from that same folder every time, a project effectively accumulates context over time. Instead of re-explaining who you are and what you’re working on in every new chat (a familiar frustration with generic chatbot interfaces), the agent can look back at everything stored in that project folder, including rules files and prior conversation history, and orient itself immediately. That’s a direct consequence of the project simply being a persistent location on disk rather than an ephemeral chat session.
Why does “local” matter if everything feels like it’s in the cloud?
Most people today assume everything lives in the cloud by default because services like Google Drive, Dropbox, or OneDrive sync automatically. But Codex’s local files aren’t automatically shared anywhere. If a file sits in a project folder and hasn’t been pushed through a sync service, it exists on exactly one machine.
This creates a very ordinary but easy-to-forget failure mode: you can’t open a local file or a locally generated output from a different computer. The video’s framing is a useful mental model: forgetting to save a Word document and then needing to email it to yourself to work on it from another laptop. That friction exists precisely because the file was local. The same logic applies to anything Codex builds or runs locally, including live previews.
What does a “localhost” preview actually mean?
When Codex generates something like a small website or a visual preview (for example, rendering a batch of motion graphics as a browsable site), it can serve that output using a local web server. The address looks like a normal URL, something in the form of 127.0.0.1 followed by a port number, but it only works on the machine where that server is running.
This matters because the URL format can be misleading. It looks like something you could copy, paste into an email, and send to a collaborator. In reality, nothing is hosted anywhere publicly. If you sent that link to someone else, their browser would try to reach a server on their own machine, find nothing there, and fail. The preview is a local-only convenience for inspecting output quickly, not a shareable deployment.
How does this connect to agents.md and routing?
Separately from the local/cloud distinction, Codex relies on a file called agents.md, a plain markdown file that sits inside a project and acts as the ground rules for how the agent should behave in that specific project. It’s read before every message in a session, meaning the agent effectively re-orients itself against those rules each time you start a new conversation.
Plans first. Then code.
Remy writes the spec, manages the build, and ships the app.
For large projects with many files and folders, the agents.md file can also function as a routing map: pointers telling the agent where to look for specific categories of information (business documentation in one place, brand voice guidelines in another, active project files somewhere else). This routing layer is what lets an agent work efficiently inside a sprawling local project directory without the user manually pointing it to every relevant file each time.
The practical takeaway: the local/cloud distinction governs where files and outputs physically exist and who can reach them, while agents.md governs how the agent navigates and behaves once it has access to that local project. They’re different layers of the same system, but both depend on the project being, fundamentally, a folder on a disk somewhere.
Is local execution a limitation or an advantage?
It’s both, depending on what you’re trying to do. Local execution means fast access to everything already on your machine, no need to upload files anywhere, and full control over what Codex can see. For a user running an AI agent as something closer to an operating system layered on their own files and work history, local-first execution keeps everything self-contained and private to that device.
The tradeoff is portability. A local project, a local preview, or a local file doesn’t travel with you to another machine unless it’s deliberately synced or exported. For workflows that depend on cross-device access or sharing outputs with other people, something has to bridge that gap, whether that’s a sync service, a deployment step, or deliberately publishing an output somewhere reachable outside the local machine.
Neither mode is strictly better. The right choice depends on whether the work is personal and self-contained (where local is simpler and more private) or collaborative and multi-device (where cloud accessibility becomes necessary).
Frequently Asked Questions
What does “local” mean in Codex?
It means a file, folder, or output exists only on the specific machine being used right now and isn’t reachable from any other device unless it’s explicitly synced or shared.
Can I share a Codex localhost preview link with someone else?
No. A localhost address like 127.0.0.1 with a port number only resolves on the machine running that local server. Sending the link to someone else won’t let them view the same content, because nothing is hosted publicly.
How does a project folder relate to local versus cloud?
A Codex project is just a folder of files and subfolders on disk. Whether that project is “local” or effectively cloud-accessible depends entirely on whether that folder is being synced through a service like OneDrive or Google Drive.
Does agents.md control local versus cloud behavior?
No. The agents.md file sets rules and routing instructions for how the agent should behave and navigate within a project. It doesn’t determine where files physically live; that’s governed separately by whether the project folder is synced anywhere.
Why would a file that started as local suddenly become cloud-accessible?
If that file sits inside a folder connected to a sync service, any change gets pushed up and becomes reachable from other devices logged into that same sync account, turning a once-local file into a cloud-accessible one without changing anything about how Codex itself handles it.