On July 9, 2026 OpenAI launched ChatGPT Work, an agent product designed for knowledge work. The release included three new models across fourteen configurations, consolidated the ChatGPT and Codex desktop apps, and presented cloud agents in a more accessible form. OpenAI reported that three weeks after launch Work (together with Codex) had crossed 10 million users. (Editor’s note: ChatGPT was estimated to reach 1 billion MAU in June and 1 billion WAU this month.)
Work is an agent that connects to the tools you already use — Slack, email, Drive, calendars, CRMs, project trackers and hundreds of plugins — gathers context across them, and produces finished artifacts such as docs, sheets, slides and hosted web apps (Sites).
Runtime: Codex harness and a cloud machine
Work runs on the Codex harness: it inherits the same models, subagents, browser use and the ability to grind on tasks for hours. Its UI omits development‑oriented traces (git controls, diff traces) so it doesn’t read like a coding agent.
The agent executes on an isolated, beefy microVM in the cloud. Pro accounts receive 8 CPUs, 20 GB of RAM and a 64 GB disk; Plus accounts are listed with 14 GB of RAM. The VM is paired with a managed Chrome service that the agent controls via tool calls.
Every new Work conversation is treated as a task. On web and mobile, Work runs in the cloud: you can start a task in the browser, track progress and give directions from the ChatGPT phone app, then view the resulting report or spreadsheet on your laptop.
The desktop app supports two modes: cloud and local. In cloud mode tasks run in the same cloud machine and sync across web and mobile. In local mode the agent works directly on your device with full computer use across files and apps; local tasks don’t appear on web or mobile and currently cannot be moved to the cloud. Desktop local mode therefore resembles Codex’s local behavior, minus the code‑centric UI traces.
For the rest of this piece, Work means Work in cloud mode.
Persistence and memory
Work’s cloud computer is persistent: the workspace is synchronized to durable storage and restored onto isolated microVMs as needed, so the underlying machine can change while the working state carries over. Compared with OpenClaw experiments, however, the agent has far less sovereignty over that machine.
Each Work task gets a working directory under /workspace/scratch where the agent can create folders, install dependencies, write scripts, maintain databases and run ordinary Linux searches. For example, if asked to prepare an Acme presentation the agent can create clients/acme, copy in source material, run analysis via code and produce charts and slides as files in that directory. When you follow up in the same thread the agent returns to that working state and continues editing.
But when a task needs context from other threads, the agent does not treat other threads’ working directories as a shared workspace it can freely navigate. Instead it relies on the ChatGPT product layer. By default each new thread receives a compressed summary of recent tasks and files; raw conversation transcripts are not stored on the machine for browsing. If a task needs details from previous threads, the agent calls Personal Context, a dedicated tool that queries Chat and Work history via a separately managed service and returns relevant excerpts.
Files follow the same model. ChatGPT’s Library is the central, user‑facing repository for files and artifacts. User uploads land there automatically; agent‑created files are saved there when the user requests it or when the agent judges them worth retaining. The agent can create directories in the Library to organize it. The Library does not live on the cloud machine and is reachable only via dedicated tools.
A file thus exists in two places: a working copy inside the thread and a canonical item in the Library. The two do not automatically synchronize. If Thread A uploads a file and Thread B later changes the Library version, Thread A will continue to read its stale local copy when resumed.
An agent can be instructed to navigate other tasks’ scratch directories, find files and modify them, but it won’t do so on its own. The directories have opaque names, no legible map to their conversations, and no stated retention contract.
Memory is managed externally as well. ChatGPT’s primary memory primitive is a running synthesized profile of the user that the product maintains asynchronously and supplies to Work when a task begins. The agent can reason from that profile but cannot modify it directly.
ChatGPT Projects carry into Work. Projects group related conversations, standing instructions and Sources (user‑uploaded files). A new task in a Project receives the Project instructions, summaries of relevant conversations and local copies of Sources in its directory. The Project itself is an abstraction maintained by the product rather than a directory on the machine.
In short: the agent has broad freedom within a task, but continuity across tasks is mediated by an opinionated ChatGPT product layer rather than by the machine itself. Likely reasons include building on existing ChatGPT primitives (Conversations, Library, Personal Context, Memory), user safety concerns around unrestricted access to a unified environment, and OpenAI’s desire to retain product control over UI, context management, sharing, sync and versioning.
A meta‑layer agent that coordinates across tasks and projects is currently missing but could arrive later.
Early signs of useful proactivity
Most AI products remain reactive: the user must notice a need, gather context and convert it into a prompt. Work shows an initial glimpse of proactivity. When you open a new Work conversation, alongside the composer you get personalized task suggestions generated from your context.
One suggestion prepared me for an upcoming call: it had inferred from a calendar event that preparation would help, pulled data from Calendar and Gmail and framed a task aligned with preferences stored in my memory. When I accepted and sent the injected prompt, the agent produced a high‑quality meeting brief. Today Work suggests tasks but does not execute them autonomously; true proactivity would require completing predicted tasks without the user in the loop — a near but not yet realized capability.
Scheduled tasks
Automations let Work run tasks at a future time or on a recurring schedule. OpenAI introduced the underlying scheduler as Scheduled Tasks in January 2025; Work builds on that scheduler and makes runs agentic so each run can use the agent’s context and tools.
There are two types:
- Standalone scheduled task: each run starts from a saved prompt and opens a fresh task for the result (good for one‑offs or routine scans).
- Scheduled task inside an existing conversation: triggered by a “heartbeat”, it reawakens the task with its context intact (useful for monitoring or quick review loops). At the time of writing heartbeats work on the desktop app but are not exposed in Work on the web.
Automations can be one‑time or recurring, triggered at an exact time, a loose window (e.g. “in the morning”), or by a condition the agent monitors. You can create and manage automations inside a conversation, or use the Scheduled page to see every task, its next run and recent results, with controls to edit, pause or delete. The product also suggests custom automations (some generic, some personalized from memory).
Browser use
Historically ChatGPT could search and retrieve web pages or call APIs but could not click through interfaces, stay logged into services or complete multi‑step workflows. Operator and ChatGPT agent added those abilities; they became core to Codex and are now most integrated in Work.
Unlike Codex when run locally, the Work browser does not live on the same machine as the agent. The agent controls a separately hosted Chrome service via tools: it can inspect pages, click, type, scroll, take screenshots, manage tabs and dialogs, and move files between the browser and its computer. On web and desktop Work shows a replayable timeline of past browser states so you can retrace the agent’s actions. You can also take over the live browser to navigate or enter a password, then hand it back to the agent; mobile does not yet support this.
The browser service keeps a persistent profile: new browser instances inherit preferences and logged‑in sessions. The Work agent never sees this profile or credentials; instead a small permission ledger is synchronized into its computer alongside the workspace that records, globally and per conversation, which sites it may act on and whether it may move files to or from them.
But the cloud browser faces constraints a local browser does not. Some sites treat it as an unsupported session or client (Amazon US rejected it); some services time out in the cloud (Google Photos timed out when copying a shared album). Work can attempt a CAPTCHA only with your permission and is instructed not to loop or evade site safeguards.
Despite these limits, the cloud browser expands Work’s capabilities and enables classes of tasks that simple web search alone could not complete.
Plugins, skills and tools
OpenAI has iterated on multiple primitives to connect ChatGPT to outside apps: Plugins (March 2023), GPTs and Actions (November 2023), connectors (June 2025), and apps plus an Apps SDK and Directory (late 2025). In March 2026 plugins returned to Codex as packages of apps and skills. With the July 9 launch the App Directory became the Plugin Directory, existing apps were packaged into plugins and the directory extended across Work and Codex. For now OpenAI appears to have settled on plugins as the primary integration mechanism for Chat and Work.
A plugin today can contain:
- Apps that expose tools (discrete operations) to the agent via MCP servers (e.g., search messages, send email);
- Skills that package instructions with references, templates and sometimes scripts to teach workflows;
- App templates for organization‑specific configuration.
Plugins fall into three broad types: operational plugins (computer use, Sites deploy, Documents/Presentations/Spreadsheets artifact creation), role‑specific plugins (e.g., Sales plugin combining many skills and apps), and service plugins (integration with Gmail, Slack, Notion, Figma, Salesforce, PitchBook, etc.).
Users can build personal plugins by connecting a custom MCP server and optionally adding skills or custom UI. Developers who want wider distribution can submit plugins to OpenAI for publication in the Plugin Directory. The directory already holds more than 1,000 plugins covering most major apps and services, but discovery remains weak: Work routes tasks to installed plugins, but it doesn’t suggest relevant plugins when one is missing. For example, when asked to search for flights and hotels Work used web search instead of recommending or leveraging travel plugins that might have been installed or installable and could have completed bookings more efficiently.
This raises product questions: when should ChatGPT handle a task directly, when should it recommend a plugin, and which plugin should it prefer if multiple are capable? Without improved discovery OpenAI leaves on the table value for users, developers and its platform ambitions.
What’s next
When Work folds into Chat later this year its design decisions will become the default experience for a billion people. Before that happens OpenAI needs to address tensions surfaced by usage:
- Will the cloud machine become the user’s primary AI computer and how will local/cloud sync feel seamless?
- Will Work agents gain more OpenClaw‑style sovereignty over that machine, or will ChatGPT’s opinionated continuity role persist?
- How will Work be taught to Chat users so they understand its purpose and how to use it effectively?
None of this diminishes that Work is an ambitious and technically rich launch: it consolidates years of scattered products and experiments into a more coherent whole and approximates what ChatGPT might look like if designed today around modern agent capabilities. It will be important to watch how OpenAI evolves the architecture, the sharing and sync semantics, plugin discovery and the balance between agent freedom and product controls.
The author spends most of their time thinking about personal AI and invites readers to continue the conversation on X or via their website.



