ChatGPT Work vs Chat: What OpenAI's New Agent Mode Actually Adds, and Whether It Is Safe OpenAI's ChatGPT Work mode, launched July 9, 2026, adds agentic capabilities beyond standard Chat, including a sandboxed browser, persistent disk, and sub-agents, as detailed by developer Simon Willison. Willison's analysis reveals 223 registered tools and 44 hidden skills, raising security concerns due to the combination of capabilities that align with his 'lethal trifecta' model. 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 https://simonwillison.net/2026/Aug/30/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 https://simonwillison.net/2025/Jun/16/the-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. 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. 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: 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. 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 https://codex-tool-reference.simonw.chatgpt.site/ , 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. Willison's lethal trifecta model says an AI system is dangerously exposed to prompt injection when it combines three capabilities: 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 https://simonwillison.net/2025/Jun/16/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. 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: 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. 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.