OpenAI announced ChatGPT Work on July 9, 2026, and has been iterating on it furiously ever since. It has a Chat tab and a Work tab sitting side by side, and the official documentation tells you Work is for tasks "with a clear outcome, such as a brief, deck, analysis, recurring update, workflow, or file you can review and use." That description is almost useless, because I have been asking regular ChatGPT Chat for briefs, decks, and analyses for three years.
Last week Simon Willison did the work OpenAI should have done and published his findings in a post called Understanding ChatGPT Work. He mapped what the Work mode actually is, what tools it secretly has, and where it sits on his own security model. The punchline: it is far more capable than the marketing suggests, and it combines exactly the three ingredients his lethal trifecta model warns about.
This article unpacks what Willison found, translates it into a plain-language comparison of Work vs Chat, and explains why the security question is the part that should concern every professional who is about to point this thing at real work documents.
First, the naming mess, explained in one minute
Part of why nobody understands ChatGPT Work is that it is not one product. Willison breaks it into two.
Work Cloud. The version that runs in the cloud, reachable from chatgpt.com and the mobile apps. This is the powerful one, and the one Willison spends most of the post on.
Work Local. Install the ChatGPT desktop app, which used to be called Codex, and you get a Work mode that can access files and run programs directly on your computer. Willison's read: this is basically regular Codex re-skinned to feel less intimidating to non-developers.
There is also a "Where should this chat run?" dropdown in the desktop app, so the boundary is blurry even inside OpenAI's own UI. If you have been confused about what ChatGPT Work even is, you are not missing anything. The confusion is the product design.
One more gate: Work is for paid subscribers only. Free users and $8-per-month Go users do not get it. You need the $20/month Plus tier or above.
Work vs Chat: the feature gap, feature by feature
The honest question is not "when should I use Work?" but "what can Work do that Chat cannot?" Willison, after extensive experimentation, lists the deltas. Here they are, translated into a side-by-side you can actually use:
- Model selection. Work exposes GPT-5.6 Sol, Luna, and Terra, each with reasoning levels from Light up to Max and Ultra. Chat offers a different lineup: 5.6 Instant through Pro, where Extra High and Pro are reserved for $100/month subscribers. Pro appears to be Chat-exclusive with no Work equivalent.
- Internet-connected code execution. This is the headline capability. Work's code environment can talk to the rest of the internet: install packages, call APIs, fetch web pages. Chat's sandbox is walled off behind a container proxy that blocks all of that.
- A headless Chrome browser. Work can launch a full Chrome instance, load websites, fill out forms, take screenshots, and even run JavaScript against the DOM of loaded pages. If a site needs sign-in, the browser hands control to you for passwords and 2FA codes, so credentials never pass through the model itself.
- A persistent, shared filesystem. Every Work session gets a scratch folder, and those folders persist across chats. Willison reports 171 folders in his /workspace/scratch. Chat gives you no persistent workspace at all.
- ChatGPT Sites. Work can build and deploy entire websites on Cloudflare Workers, including stateful server-side features on D1 and R2. Willison demoed this by prompting Work to research a topic, generate a JSON file from it, and deploy a working site about it.
- Sub-agents. Chat cannot run sub-agents. Work can, in parallel, with Sol, Luna, and Terra. Willison calls it a power-user feature for complex projects that benefit from multiple agents working together.
- Scheduled automations. Recurring prompts on a schedule, possibly also present in Chat, but most visible in Work.
Read that list back and a clearer definition of Work emerges: ChatGPT Work is what you get when you give ChatGPT a computer. A sandboxed one with a browser, a persistent disk, outbound internet, and a fleet of sub-agents. Chat is the model answering questions. Work is the model doing things.
How Willison figured all this out (and why he had to)
None of this is in OpenAI's documentation, because OpenAI still hides its system prompts and tool descriptions. Willison's method is worth studying in itself, because it is the same play he has run before and the same play any of us can run.
He simply asked the Work agent to enumerate itself. He had Work list its registered tools, and then publish the full inventory as a website: 223 registered tools, of which 6 came from his own personal MCP servers. When he noticed the only browser-related tool listed was web.run, which did not look like enough to explain the full browser feature, he got suspicious and dug further. The real browser power was hiding inside Skills: ChatGPT Work ships 44 of them, and a control-browser skill explains that browser interaction flows through a Node REPL and a browser-client runtime.
One prompt to the agent, "add full copies of every skill to the website", and the entire hidden instruction set was public, including the full output of the browser documentation call.
Two takeaways here for anyone building with agents. First, an agent with code execution and a persistent filesystem is an agent that can be made to document itself, which is a genuinely useful debugging and auditing technique. Second, the fact that this passes for reverse engineering in 2026 says something uncomfortable: OpenAI still refuses to publish system prompts, so independent researchers do this detective work for them, for free, on every release.
Now the part that matters: is it safe?
Willison's lethal trifecta model says an AI system is dangerously exposed to prompt injection when it combines three capabilities:
- Access to private data
- Exposure to untrusted content, anything from the open web, emails, or documents you did not write
- A channel to communicate data out, to the same open internet
His verdict on ChatGPT Work is blunt: it combines all three. Private data goes in through your files, your previous session folders, and your ChatGPT account. Untrusted content comes in through that internet-connected code environment and the headless browser visiting arbitrary pages. And the exfiltration channel is the same outbound internet access that makes the feature exciting in the first place.
Concretely: an agent that can read your workspace files and also fetch a URL can, in a prompt-injection scenario, be instructed by a web page to send your data somewhere. That is not a hypothetical bug class. It is the same structural risk he flagged in his June 2025 essay on the lethal trifecta, now shipped to millions of $20-per-month subscribers as a default product surface.
What is OpenAI's defense? Willison expects it is the same auto-review mechanism Codex uses: a second model that reviews the agent's actions for signs of manipulation before they execute. That may raise the cost of an attack, but it is a mitigation, not a fix. The structural combination of the three capabilities remains.
His ask of OpenAI is simple and reasonable: publish the system prompts and tool descriptions. If the Work documentation included the exact instructions the agent runs under, most of the reverse engineering would be unnecessary, and users could actually evaluate the security posture of the thing they are connecting to their work lives.
What I would actually do with this, today
I run my own AI agent infrastructure on a small VPS, the same kind of loop-with-tools setup Work now offers as a consumer product, and I run it with the lethal trifecta in mind. Full disclosure: I have not paid for ChatGPT Work, so everything above comes from Willison's hands-on findings and OpenAI's documentation, not my own sessions. But the decision framework applies either way:
- Low risk: drafts, research summaries, learning a codebase, building a personal site in the sandbox, anything with no private data in the blast radius. The browser tool doing public research is a legitimately great feature.
- Medium risk: connecting your own files to a web-connected agent. Useful, but treat the agent as a junior employee who can be fooled by a convincing web page. Do not hand it a folder you would not hand a stranger.
- High risk, avoid for now: anything where credentials, client data, or financial documents are in the same workspace as untrusted web content. Until OpenAI publishes its actual containment model, the honest answer is that nobody outside the company knows how good the walls are.
If you are evaluating agent products for your team, the checklist I use: Where does private data live? What untrusted content can reach the agent? What network egress does the sandbox have? Who reviews actions before they execute? If the vendor will not answer all four, the lethal trifecta question is unanswered, and you are beta testing with your data.
The bigger story
Two things stick with me from this episode.
First, the capability jump is real. Internet-connected code execution, a scriptable browser, persistent storage, deployable websites, and parallel sub-agents inside a $20 subscription is a serious computer-in-the-cloud, and most people looking at the Chat vs Work tab selector have no idea. Confusing product naming is hiding a genuine power tool.
Second, the transparency gap is getting wider, not narrower. We are at the point where the most capable consumer agent ever shipped runs on hidden instructions, and the public's understanding of it depends on one researcher asking the agent to describe itself. That is not a healthy equilibrium, and OpenAI could fix it with one documentation page.
I write about AI, developer tools, and the systems behind them every week. Subscribe, it is free, and it helps me keep doing this.
Have you tried ChatGPT Work yet? Did the Work tab confuse you too, and did you find a use for the browser or the persistent workspace that actually stuck? I am collecting real experiences for a follow-up.
