OpenAI’s ChatGPT Work, introduced July 9, splits into a cloud tier and a desktop tier built on the old Codex app. Independent developer Simon Willison spent the back half of August probing the cloud version because OpenAI’s own documentation would not tell him what it actually does. His conclusion, laid out in a detailed post on his blog: the cloud tier is not a chat product with extra polish. It behaves like a general-purpose computer with a network connection, wrapped in a language model.
Access starts at the $20 a month subscription tier. Free users and the $8 a month Go tier get nothing. Inside that paid tier, Willison found model selection across three variants he refers to as Sol, Luna, and Terra, each available at reasoning levels running from Light up through Ultra, mirroring the raw options exposed through OpenAI’s API rather than the simplified picks offered in ordinary ChatGPT Chat.
His hands-on testing turned up a set of capabilities missing from Chat entirely:
- A code execution sandbox with open internet access by default, not the blocked container proxy that Chat uses
- A headless Chrome browser that loads pages, fills out forms, takes screenshots, and runs JavaScript against a live page
- A filesystem that persists across sessions instead of resetting with every new chat
- The ability to deploy finished projects as live sites running on Cloudflare Workers
- Sub-agent sessions spun up using any of the three models
- Scheduled prompts that run on a recurring cadence and can flag new information without a human checking in
Willison singles out the open internet access on code execution as the standout addition. He compares it to Claude’s equivalent sandbox, which has allowed restricted outbound access since last September but only to a short list of package registries and GitHub. Work’s default configuration, by his account, reaches further: clone a repository, install its dependencies, then use the result to interact with arbitrary sites on the open web.
His sharper argument is about safety, not convenience. He frames the risk through a concept he calls the lethal trifecta: an agent becomes dangerous once it can read private data, take in content from sources it does not control, and send information back out over the network, all inside the same session. A malicious instruction hidden in a scraped page or an uploaded file does not need a person to read it. The model reads it and can act on it directly, a failure mode commonly called prompt injection. Willison argues ChatGPT Work combines all three elements of the trifecta at once: filesystem access, an open-ended browser, and outbound reach to the internet.
He says he would like OpenAI to explain how Work sessions are defended against that failure mode and expects the answer mirrors the auto-review mechanism already built into Codex. OpenAI has not published that detail alongside the product itself, which Willison also faults for describing Work by its intended use cases rather than by what its tools and system prompt actually let it do.
That gap points to the real story here, beyond any single feature. A code sandbox with open network reach, a browser that can sign into other services, a shared filesystem, and the ability to publish live sites is not a productivity tool with a few rough edges. It is a general-purpose computer attached to a language model, provisioned by default with broad access to the rest of the internet.
Teams weighing a Work rollout are not deciding whether it saves time on decks and status updates. They are deciding how much access to grant a model that can hold credentials, ingest untrusted content, and reach outbound systems within a single session, and whether their current review process would catch an injected instruction before it acts. That evaluation belongs with whoever owns security, not with whoever owns the ChatGPT seat license.
Simon Willison, “Understanding ChatGPT Work,” published August 30, 2026.
