A headless Chrome browser, an internet-connected code runner, a persistent workspace and hosted websites now sit behind ChatGPT's Work tab. In a hands-on inspection, developer Simon Willison found 223 registered tools, six of them supplied by his own MCP servers, plus 44 skills. OpenAI has not published that inventory as an official catalog. It still shows the scale of the runtime hiding inside a familiar chat interface. For developers, Willison's findings make ChatGPT Work easier to understand as a hosted agent environment that happens to begin with a prompt.
OpenAI describes Work in terms of outcomes: give it a brief, analysis, recurring update, workflow or file, then review what it produces. The more useful distinction is operational. Work can use approved tools and files, keep running in the cloud, interact with websites and return artifacts after several actions. OpenAI's getting-started guide says users can follow progress, answer questions, redirect a task and approve important actions while it runs.
A task tab with an agent runtime underneath
There are two execution locations under the same name. Work Cloud runs on OpenAI-managed infrastructure and can continue after a laptop is closed. Work Local, available through the desktop app when permissions allow it, can work with files and applications on the computer. OpenAI tells users to choose Cloud for tasks that need to continue across web or mobile, and Local when the task depends on the device. That distinction is buried inside a composer control, even though it changes what the agent can reach and where the work executes, according to the official Work guide.
Willison's tests focused on Work Cloud. His session could clone repositories, install dependencies and reach websites from its code environment. It could also launch a browser, run JavaScript against a page's DOM and take screenshots. He found model selection, sub-agent sessions, shared files and Sites in the same product. The breadth explains why the Work tab can feel vague: the label covers a set of execution tools under one name, as his hands-on account documents.
The self-generated tool catalog needs a caveat. Work produced the list when Willison asked it to document its own tools and skills, and six of the 223 entries came from his personal MCP setup. OpenAI has not published that number as a stable product specification. The result is still useful because it exposes how much behavior is routed through tools that most users never see. Willison also found a browser skill whose instructions required the agent to load browser documentation before acting, a detail recorded in his tool inspection.
The browser is the security boundary users can see
OpenAI's browser can open pages, click, type, inspect rendered state and capture screenshots. It is available in ChatGPT on the web and in the desktop app, while the Codex CLI and IDE extension do not include it. The desktop browser uses a profile separate from a person's regular browser and does not automatically inherit existing tabs or login sessions. Users can sign in inside that profile when a task requires an account, according to the browser documentation.
That separation limits accidental access to an everyday browser session, but a signed-in Work browser can still encounter hostile instructions embedded in pages. OpenAI explicitly tells users to treat page content as untrusted and to review a site and the proposed action before sharing sensitive information or allowing the agent to proceed. The warning matters because the same browser can gather current information and complete multi-step actions, as the official browser guide explains.
Cloud execution has a different perimeter from local execution. OpenAI says a cloud task does not inherit local files, desktop apps, private-network access or the device's browser session. It can receive text entered in the conversation, uploaded or project files, data returned by an authorized app, and website content reached through an enabled browser. The current cloud path uses VM-backed sandboxes on shared OpenAI infrastructure, with state associated with the authenticated account, according to OpenAI's cloud security documentation.
Connected accounts widen that perimeter deliberately. Workspace administrators can decide which apps and plugins are available, which account scopes they receive, and whether supported reads or changes require confirmation. OpenAI says some configurations can ask on every use, on any change or only for important actions. Those controls reduce exposure when they are configured carefully. They do not answer Willison's larger question about how Work detects prompt injection after untrusted web content and private connected data enter the same task. OpenAI's security guide describes access controls, while Willison's assessment identifies the unresolved attack path.
Persistent files change how sessions accumulate state
Ordinary chat sessions have usually trained users to think in disposable conversations. Willison found 171 scratch directories in his Work Cloud workspace, each retained from an earlier session. He reported that multiple active sessions could see edits in the shared filesystem even though their running processes and localhost servers remained separate. That means a task can leave behind source files, downloaded data or generated artifacts for a later task to reuse, based on his filesystem tests.
OpenAI's enterprise documentation confirms the broader behavior without promising Willison's exact directory layout. Work Cloud can reuse an environment across tasks or replace it while preserving eligible state. Each task runs on shared, OpenAI-managed infrastructure. Customers do not receive dedicated physical hosts. Teams therefore need to treat cloud files as durable account state and set retention expectations accordingly; OpenAI says retention and audit visibility vary by data category, storage location and workspace configuration in its cloud security guide.
Persistence also changes the value of scheduled work. OpenAI recommends Cloud for jobs that check websites over time because those runs do not depend on a user's computer staying awake. Willison demonstrated a scheduled search and noted that schedules can be combined with Work features, such as updating a Site. A useful automation can therefore span browser access, stored artifacts and repeated runs. Each added permission increases the amount of state a later task may inherit, a connection supported by the Work guide and Willison's schedule test.
Sites turns an agent result into a live deployment
Sites is in public beta for Plus, Pro, Business, Enterprise and Edu plans. It can create, host and revise websites, web apps and games from a prompt or compatible project. OpenAI warns that every Sites deployment URL is a production deployment; users who want a private review step must ask ChatGPT to save a version without deploying it. The Sites documentation also says plan-specific limits can restrict new deployments, storage or continued public access for a busy site.
The feature goes beyond static HTML. OpenAI documents durable application data, uploaded files, optional Sign in with ChatGPT and built-in traffic analytics. In Willison's test, Work built a public research site and used Cloudflare Workers with D1 and R2 for server-side and stateful features. His implementation details are observations from one generated project, while the supported product behavior comes from the official Sites guide and his published experiment.
For a developer, that short path from research to a public URL is useful for prototypes and internal tools. It also compresses several review steps into one agent session. Source accuracy, dependency behavior, access rules and deployment status can all change during the run. OpenAI's own sequence asks users to describe, review, refine, then manage and share a Site, and its production-URL warning makes the review stage concrete in the Sites guide.
Availability and limits are still difficult to read
The product map is moving quickly enough that current sources disagree. Willison wrote on August 30 that Work appeared limited to subscribers paying $20 a month or more. OpenAI's current pricing page says ChatGPT Work and Codex are included in Free, Go, Plus, Pro, Business, Edu and Enterprise plans, while Sites has its own narrower list of eligible plans. The documents do not explain whether the difference comes from rollout timing, account eligibility or a recent change. OpenAI also says capabilities depend on plan, rollout and configuration in its pricing page and cloud security guide.
Usage is another shared boundary. OpenAI says Work and Codex draw from the same pricing, credits and usage limits, with consumption affected by model choice, context, reasoning, tool use, retrieval and caching. A large browser task or multi-agent job may therefore consume a different amount from a short request even when their prompts look similar. The official pricing documentation advises that prompt length alone is a poor estimate.
OpenAI has supplied separate pages for Work, Browser, Sites and cloud security, yet the interface still asks users to reason about them as one tab. Willison's investigation found the feature set by experimentation and by asking the agent to reveal its own tool descriptions. A public capability matrix, a dated change log and a direct account-level view of enabled permissions would make that boundary easier to audit. His account of the discovery process shows why the current task-oriented description leaves technical users searching for lower-level details.
The next evidence to watch is specific: documented prompt-injection tests for the cloud browser, clearer retention rules for shared files, stable plan-by-plan limits for Work and Sites, and an account-level permission export. OpenAI already tells users to distrust page content and review actions, while its security page says audit visibility varies with configuration. Teams evaluating Work should begin with a separate browser profile and low-privilege connected accounts. Their first Site should be disposable. They should also record exactly what the task could read, change and publish. Those boundaries are the ones OpenAI identifies in its browser, Sites and cloud security documentation.