ChatGPT Work Mounts One Filesystem Into Every Session You Have Running
What /workspace actually is, why OpenAI's own getting-started page never mentions it, and why the reviewer everyone assumes is the injection defense would never be asked to look
OpenAI's official page for getting started with ChatGPT Work is under a thousand words. It explains that Work is for tasks with a clear outcome. It gives you four example prompts, one for a deck, one for a comparison spreadsheet, one for a Monday recurring update, one in a best-practices section. It tells you to install plugins and type @ to point at them.
It never mentions a filesystem.
Simon Willison published a working teardown of the product on August 30, and it is the most useful document about ChatGPT Work that exists, including OpenAI's own. Work Cloud has a persistent volume at /workspace. Each session gets its own scratch folder under it, named something like /workspace/scratch/e00a0a017944, and those folders survive after the session ends. Willison counted 171 of them in his own account. Then the part that should stop you: "As far as I can tell that /workspace volume is mounted to all Work sessions that are currently running, file edits from one can be instantly seen by the others."
Two properties, and they are separate. The volume is durable, so a file written last Tuesday is still there. The volume is also shared live, so a file written thirty seconds ago by another running session is already visible. That is a shared mutable disk between agent runs. It is the most security-relevant fact about the product and it appears in a personal blog post rather than in anything OpenAI publishes.
The position
I think this is the most under-discussed piece of agent infrastructure shipped this year, and the reason is boring: nobody can discuss what nobody has written down. Willison had to reverse-engineer a product OpenAI announced on July 9 because, in his words, OpenAI explains Work in terms of what it is for rather than what it does, and still will not publish the system prompt or the tool descriptions. His verdict on the effort: "Figuring this all out took way more work than it should have."
That is not a documentation nitpick. When he asks whether ChatGPT Work is safe, he answers by pointing at his lethal trifecta model from June 2025: private data, exposure to untrusted content, and a channel to send stolen information out. Work Cloud has all three. Its code execution environment can reach the open internet, and while Willison notes it "can be configured with a specific list of allowed domains," he found "the default appears to be open to all." It drives a full headless Chrome that runs Playwright against page DOMs. It deploys live sites onto Cloudflare Workers with D1 and R2 behind them. It runs sub-agents.
Willison guesses OpenAI's protection is the same auto-review mechanism that Codex uses. Note that this is his guess, not OpenAI's statement. It is a reasonable one, and it is the only candidate anyone has named, so I went and read that document carefully. If auto-review is the answer, its trigger condition is the whole story.
What auto-review actually watches
Auto-review is well documented, which makes the contrast sharper. It replaces a human approval prompt with a separate reviewer agent. The main agent keeps working inside read-only or workspace-write. When it needs to cross the sandbox boundary, it files an approval request, and if approvals_reviewer = "auto_review" that request routes to the reviewer instead of stopping for a person.
The document is blunt about scope. "Auto-review is a reviewer swap, not a permission grant. It does not expand writable_roots, enable network access, or weaken protected paths. It only changes how Codex handles actions that already need approval." And under Limits: "It only evaluates actions that ask to cross a boundary."
Read the trigger list. Shell calls requesting escalated sandbox permissions. Network requests blocked by policy. File edits outside the allowed writable roots. MCP or app tool calls annotated as requiring approval. Computer Use reaching a new domain. Against that, "Auto-review does not run for routine actions already allowed inside the sandbox."
The document even anticipates the shape of the gap in a different context: "A network destination on the allowlist doesn't trigger review by itself. Add explicit command rules with decision = \"prompt\", or configure sensitive MCP tools to require approval, when actions inside the sandbox must still reach the reviewer." Allowed actions are invisible to the reviewer by design, and you have to opt them back in by hand.
Now hold that against /workspace. I have to be careful here, because nobody has published Work Cloud's sandbox configuration, so I cannot tell you with certainty that /workspace/scratch sits inside a writable root. What I can say is that a session writing into its own scratch directory is the most ordinary thing an agent can do, and if it required an approval request every time, the product would be unusable. Assume it does not. Then it generates no approval request, and there is no request for a reviewer to review.
The boundary model assumes the dangerous thing is reaching out. On a shared volume, the dangerous thing is reaching sideways. A file written by session A and read by session B has moved between two trust contexts without ever leaving the sandbox that both of them live in.
Picture the concrete version. You have a scheduled automation running every morning that browses a set of vendor pages and writes notes into its scratch folder. You have a second Work session where you are drafting something against your own private files. The scheduled run visits a page containing text addressed to an agent rather than to a human. That text does not need to exfiltrate anything itself. It only needs to get a sentence written into a file on a volume the other session can see, either right now or next Tuesday.
I want to be precise about what I am and am not claiming. I have not demonstrated this. Nobody has published a working exploit against Work Cloud's shared volume that I can find, and the absence of a demonstration is a real thing to weigh. The narrower claim is the one I will defend: the defense mechanism people assume covers this has a documented trigger condition that this pattern does not obviously meet, and OpenAI has published nothing describing a different one.
Put this into practice
None of this requires you to stop using Work. I use it. These are the lowest-friction moves, roughly in order of value per minute.
Get the tool list out of the product itself. This is the best thing in Willison's post and it arrived after he published it. He started a fresh Work session and asked it to document its own tools, and the result is a site listing 223 registered tools (six of them his own MCP servers) and, in his words, "It turns out ChatGPT Work uses a lot of skills, 44 in fact!" You can run the same prompt in your own account in about five minutes. Stop waiting for OpenAI to publish the tool descriptions and have the agent enumerate them for you.
Look at your own volume. Ask a Work Cloud session to list /workspace/scratch with counts and modification dates. Willison's 171 folders were an accident of using the product, not of trying to accumulate them. You will probably be surprised by how much is sitting there and how old some of it is. Fifteen minutes, and it converts an abstract worry into a specific inventory.
Set the domain allowlist. Willison found the default appears to be open to all, and configuring a specific list of allowed domains is the one mitigation that is both documented and under your control. It shrinks the untrusted-content side of the trifecta directly. Do this before the habit changes below, because it is the only one that is a setting rather than a discipline.
Separate trust levels in time, and then clean up. Do not run a session that browses the open web or processes a document someone sent you at the same time as a session holding your private files and plugins. That handles live cross-session visibility. It does not handle persistence, because the scratch folders outlive the session, so pair it with deleting or moving scratch output you no longer need. The first habit is free; the second is the one people skip.
Audit your scheduled automations specifically. They run while you are not looking, which makes them most likely to be concurrent with something else by accident. For each one, write down what untrusted content it touches. A daily prompt that reads news sites and writes a summary is exactly the shape described above. (Willison originally listed scheduled automations as a Work-only feature and then corrected himself: "Actually this seems to work in ChatGPT Chat as well." The audit applies to both.)
Prefer Work Local for anything sensitive. The desktop version, in Willison's phrasing, "feels more like regular Codex re-skinned to be less intimidating to non-software-developers." Codex has a real config surface: approval policies, writable roots, prefix rules, permission profiles. Work Cloud gives you a tab selector. I have not verified how much of the Codex config Work Local exposes to a non-developer, so treat this as a direction rather than a recipe, but the direction is right.
Honest limitations
The shared-mount claim is one person's observation, hedged by that person. "As far as I can tell" is doing real work in that sentence. Willison also notes the sessions do not share process space, and a localhost server in one is unreachable from another, which means isolation is real at the process layer and porous at the storage layer. That is a specific finding, not a general claim that Work has no isolation.
My auto-review reading is an inference, not a disclosure. OpenAI has not said auto-review is what protects Work Cloud. Willison guesses it is, I read the document and concluded its trigger condition looks like it excludes intra-sandbox writes, and both of those steps could be wrong. It is entirely possible Work Cloud runs something else, unpublished, that handles this. That possibility does not help you evaluate the product, which is the actual complaint.
The auto-review document is also written for Codex, with config.toml, writable_roots, and managed enterprise requirements. Whether any of that vocabulary applies to Work Cloud is unknown. I am reasoning about a mechanism in the environment it is documented for and then reasoning by analogy about one it is not.
The product is moving fast enough that this piece has a shelf life. OpenAI has been iterating on Work since July 9 without a changelog anyone can read. Willison notes that ChatGPT Chat gained the ability to install packages in January and that it "doesn't seem to work any more," followed by "I wish they had better changelogs!" His own post gained two significant sections after publication. Everything above could be stale by the time you read it, and you would have no reliable way of knowing.
And the shared volume is genuinely useful. Picking up a file from a chat you had last week is a real capability Chat does not have. I am not arguing the feature is a mistake. I am arguing it is a security-relevant feature shipped with less documentation than a Rust CLI at v0.7.0, and that the gap got filled by a blogger.
What to do with this
The thing worth internalizing is not "ChatGPT Work is dangerous." It is that the mental model most of us carry, where an agent's risk surface is the boundary it might cross, stops describing reality once the agent has durable shared storage. Boundary-crossing is a fine trigger for a reviewer. It is a poor definition of the attack surface, because a shared writable volume lets information move between trust contexts while every individual action stays comfortably inside the fence.
So the question to carry into any agent product, not only this one: what does this system persist, who else can see it, and does any check fire on a write that never leaves the sandbox? For most products shipping right now the answer to the third part is no. Knowing that is worth more than any single finding about /workspace, and unlike the finding, it will still be true next month.
Sources: Simon Willison, "Understanding ChatGPT Work," 30 August 2026; OpenAI, "Get started with ChatGPT Work"; OpenAI, "Auto-review"; OpenAI, ChatGPT Work announcement, 9 July 2026; Simon Willison, "The lethal trifecta," 16 June 2025.