ChatGPT Work's open internet access is the real news, not the rebrand

OpenAI shipped ChatGPT Work on July 9th, and Simon Willison has spent the past seven weeks reverse-engineering it. His write-up is the clearest map yet of a product that OpenAI itself seems unwilling to explain. The headline finding: ChatGPT Work is not one product but two, and the cloud version carries capabilities that regular ChatGPT Chat has never had.

Work Cloud runs on chatgpt.com and the mobile apps. Work Local is the desktop app formerly known as Codex, re-skinned for non-developers. Willison focuses on the cloud version, and what he found there changes how the agentic-AI race should be scored. ChatGPT Work can execute code with unrestricted internet access, run a full headless Chrome browser that fills forms and handles 2FA, maintain a persistent filesystem shared across sessions, deploy websites to Cloudflare Workers, and spin up parallel sub-agents. That is a materially different tool from the chat box most subscribers still use.

The most consequential detail is the code execution environment. OpenAI pioneered the Code Interpreter pattern back in 2023, but it always ran in a walled container. ChatGPT Chat cannot install packages or reach external APIs; the container proxy blocks it. ChatGPT Work, by contrast, defaults to an open network. Users can configure an allowlist of domains, but the default is everything. Willison describes cloning GitHub repositories, installing dependencies, and using them to interact with the rest of the web. Claude’s equivalent container has allowed restricted internet access since last September, but only to a short allowlist: PyPI, npm, GitHub. ChatGPT Work’s openness is an order of magnitude beyond that.

This is the story’s real news. A frontier model with unrestricted web access, running arbitrary code, inside a session that persists across chats, is a different risk profile than a chatbot. Willison’s “lethal trifecta” framework names the danger precisely: an agent system that combines private data, exposure to untrusted content, and a channel to exfiltrate stolen information back to an attacker. ChatGPT Work combines all three. He notes that OpenAI’s likely answer is the same auto-review mechanism used in Codex, but he wants more detail. He is right to push. The company has not published the system prompt or tool descriptions for Work, which is why he had to prompt a fresh session to build a site listing all 223 registered tools.

That tool inventory is itself revealing. Willison’s prompt produced a site cataloging 223 registered tools, six of which came from his own personal MCP servers. A 217-tool default surface area is not a product; it is an operating system. OpenAI has built an agent that can read the web, run JavaScript against live DOMs, deploy stateful server-side apps on Cloudflare D1 and R2, and schedule recurring prompts that check for new information. The scheduled automations alone, like asking Work to search for a Waymo launch date in Half Moon Bay every morning at 8am, turn a chat product into a persistent background worker.

The model lineup adds another layer of confusion. Work offers GPT-5.6 Sol, Luna, and Terra at reasoning levels from Light to Ultra, plus GPT-5.5. Chat offers 5.6 Instant through Pro, with Extra High and Pro reserved for $100/month subscribers. Willison suspects the Work sessions bill against the Codex allowance, which would explain the different model menus. None of this is documented by OpenAI in a way that survives contact with the product.

The persistent filesystem deserves particular attention. ChatGPT Chat gives each session a fresh, isolated filesystem. Work persists every scratch folder across sessions. Willison reports 171 folders in /workspace/scratch. The /workspace volume appears mounted to all running Work sessions, so file edits in one session are instantly visible in others, though localhost servers do not cross session boundaries. That shared, persistent state is what makes multi-session projects viable. It is also what makes prompt injection so dangerous: a poisoned file written in one session can be read by another.

The browser tool is the feature that will make developers pay attention. Work can launch a full Chrome instance, load pages, fill forms, and take screenshots. For authenticated sites, it prompts the user to take over and enter passwords and 2FA codes without routing those credentials through the model. Willison demonstrated it by asking Work to load simonwillison.net and extract headings using JavaScript; the agent fired up Playwright and ran a querySelectorAll loop against the live DOM. He compares it to his own shot-scraper tool, now accessible from a phone. That comparison undersells it. This is a general-purpose browser automation agent with a frontier model driving it, available through a $20/month subscription.

OpenAI’s official guidance for when to use Work versus Chat is, as Willison notes, almost entirely useless. Use Chat for answers and explanations; use Work for tasks with clear outcomes like briefs, decks, and analyses. That distinction collapses the moment you realize Chat has been doing those tasks for years. The real distinction is mechanical: Work has tools Chat lacks. Model selection, code execution with internet, a browser, a persistent filesystem, site publishing, sub-agents, scheduled prompts. That is the actual product difference, and OpenAI’s marketing refuses to say it plainly.

There are two problems here, and Willison names both. OpenAI explains Work in terms of what it is for rather than what it does. And OpenAI still hides its system prompts and tool descriptions. If the documentation included the exact system prompt and tool list, his post would not have been necessary. The opacity is not an accident. OpenAI has learned that hiding the mechanics makes the product harder to audit, harder to attack, and harder for competitors to replicate. But it also makes it harder for users to understand what they are running, which is a safety problem in its own right.

The safety question is the one OpenAI has not answered. Willison wants to hear how Work protects against prompt injection, and he suspects the answer is the Codex auto-review mechanism. That mechanism remains unproven at this scale. An agent with open internet access, a persistent filesystem, and the ability to deploy public websites is a much larger attack surface than a code interpreter that cannot reach the network. The browser’s credential handling is a thoughtful design choice, keeping passwords and 2FA codes out of the model’s context. But the rest of the pipeline, from untrusted web content to executed code to deployed sites, is a chain with many links.

For AI builders, the takeaway is that OpenAI has quietly shipped the most capable general-purpose agent tool on the market, then buried it inside a confusing tab selector. The sub-agent support with Sol, Luna, and Terra, the scheduled automations, the Cloudflare-backed site deployment: these are the building blocks of the agentic future that every lab has been promising. They are here now, behind a $20 paywall, underdocumented and under-scrutinized.

Willison’s closing experiment, prompting Work to build a site listing its own tools, is the right way to audit a black box. The result, 223 registered tools with descriptions and arguments, is more documentation than OpenAI has published. The company should publish that list itself. Until it does, the most reliable source of information about ChatGPT Work will be a journalist with a prompt and a persistent filesystem.