ChatGPT Work is a ChatGPT experience for longer, multi-step tasks such as research, analysis, and creating a report or other deliverable. Use Chat for a quick answer, Work for a bounded knowledge-work task, and Codex for software development centered on repositories, terminals, tests, and developer tools. For example, Work might review supplied policy documents and draft a summary with section references. A person should still check the evidence before relying on it.
Work can use the context you provide and, where available and authorized, connected apps, files, browser capabilities, and scheduled tasks. It is a way to delegate a defined job, not a guarantee of uninterrupted execution or correct results. Access and behavior depend on the plan, device surface, workspace policy, app authorization, and rollout. Check your account for the controls you actually have.
This guide focuses on the operational question behind the product description: what should Work be allowed to do, what should be checked before anything changes, and what should happen when the evidence or permissions are incomplete?
What is ChatGPT Work?
OpenAI positions Work for research, analysis, and finished deliverables, including documents, spreadsheets, presentations, reports, and Sites. Chat is intended for conversational help and quick questions. Codex is a separate experience for software development, including repository and developer-tool work. See OpenAI’s current explanation of Chat, Work, and Codex and its ChatGPT Work product page.
Work can use supplied material and, when available and authorized, connected apps or other tools. Plan mode, where offered, can let you review a proposed approach before execution. That review is an opportunity to correct the plan, not evidence that the task will succeed. Give the task a specific output and boundary, such as: draft a report with source links; do not email it, publish it, or update records.
The useful unit of delegation is not “let Work handle it.” It is “let Work produce this bounded output from these sources, then apply this review gate before anyone acts.”
Where Work runs changes what it can access
Cloud Work on web or mobile cannot directly read files on your computer. It can work with context you provide and supported, authorized connected sources. Desktop Work can access permitted local files and desktop applications, subject to user permissions and workspace controls. OpenAI’s documentation describes cloud chats as able to sync across surfaces, while local task behavior and sharing can differ.
Local execution should not be described as fully offline. Messages and task context may be stored in the cloud, and workspace rules can restrict local access, browser use, or network access. A local task may also not be schedulable or shareable in the same way as a cloud task. Review OpenAI’s guidance on local Work and synchronization before using sensitive files.
The desktop app includes a built-in browser that can browse websites, work across tabs, download files, and support sign-in on documented surfaces. Enter credentials in the browser, not in chat. Website permissions, sign-in steps, payments, account changes, and other high-impact actions depend on the site, task, account, plan, workspace policy, and required approvals. The desktop browser guide describes the current behavior.
Local file access describes what the desktop app can reach. It does not by itself mean the task is fully offline or exempt from workspace controls. Before starting, identify where the data lives, whether authenticated browsing is needed, and the narrowest folder or account access that can complete the job.
A practical way to assign Work a job
Write a task request as a small operating contract. State the objective, permitted sources, requested format, evidence needed, actions that are off-limits, and what Work should do when evidence is missing or conflicting. Connected apps require their own availability and authorization. Installing an app does not automatically permit every read or write action. OpenAI’s app-permission guide explains the controls that may be available.
Illustrative request: “Use only the supplied policy files. Draft a two-page summary with section references and source timestamps. Note conflicting or missing evidence. Do not send, publish, delete, or change records. Stop and ask if the source versions disagree.”
Keep the AI’s responsibility separate from the decision to act. Work may summarize, classify, extract, or draft. Deterministic checks and an authorized person should decide whether required fields are present, the result is valid, and an external action is permitted.
Match the workflow to the right execution surface
Choose the surface based on the source and trigger, not just convenience. The patterns below are implementation recommendations, not official Work templates. Each gives Work a bounded role and places a gate before anything consequential happens.
| Trigger or source | Work’s bounded role | Validation gate | Destination or fallback |
|---|---|---|---|
| Cloud research: supplied files, project context, or an authorized source | Summarize evidence and draft findings with source URLs and timestamps. | Check that citations resolve, required evidence is present, and calculations or conflicts are reviewed. | Save a reviewed draft. The report owner resolves missing sources before distribution. |
| Desktop analysis: a specifically selected local folder | Read permitted files and create a separate summary with section references. | Verify references and confirm originals were not unintentionally changed. | Save a separate review copy. The file owner handles inaccessible, encrypted, or changed files. |
| Scheduled or supported app event | Summarize or classify each eligible item and propose a next step. | Confirm the exact event and app permission; check required fields and duplicate status before any write. | Send a monitoring summary to a review queue. The task owner investigates paused tasks or revoked access. |
Scheduled Tasks support one-time or recurring schedules and some documented app events, including supported Gmail, Slack, and GitHub activity. Connecting an app does not make every event available. Check the trigger condition, time zone, notification settings, active-task limit, and approval requirements during setup. OpenAI documents the current behavior in its Scheduled Tasks guide.
For a recurring report, distinguish the execution from the material it processes. One task run can contain many source items; each item can produce observations and citations; a period-level total is a separate aggregate. These are useful external records to design, not built-in Work fields.
Connected apps and Zapier MCP: verify the action, not just the app name
An app name is not a promise of a particular capability. The connector, available action, account authorization, permission scope, plan, and workspace policy determine what can be done. Before describing or deploying an action, verify its exact read or write behavior, authentication scope, rate limits, returned identifiers, approval behavior, and error response.
Zapier MCP advertises access to more than 9,000 apps and 40,000 actions. That is coverage advertised for the service, not a guarantee that every action is exposed or usable in a particular ChatGPT Work setup. The configuration involves an MCP server, selected tools, authorized app accounts, and a compatible client invoking an available action. Zapier states that it handles app connections, credentials, and rate limits for its MCP service. Organizations should still review scopes, logs, permissions, provider policies, and data flows. See Zapier’s MCP explanation.
For a consequential write, verify the target record and current state before acting. A lookup followed by create is not enough when two runs can pass the lookup before either creates the record. Use a destination-side unique constraint or transactional upsert where supported. ConsultEvo’s Zapier automation services page is relevant if you need help assessing this type of automation design.
Access, plans, and pricing change
OpenAI’s product page and Help Center describe access differently by surface, plan, workspace, and rollout. The product page currently describes desktop availability across plans and web or mobile access for eligible paid plans, while account controls can still vary. Check the live account and pricing page rather than assuming that the same Work features or limits appear everywhere.
At the time of this research check, dated November 14, 2026, OpenAI documented ChatGPT Plus at $20 per month. Pro had $100, $200, and $500 monthly tiers. The reviewed Go page did not establish a universal USD price, and Business pricing was not confirmed in this research. Prices, regional availability, and included Work or tool allowances can change. A plan’s price alone does not establish identical access.
OpenAI’s product page also advertises more than 1,400 plugins, but counts can change and availability can vary by directory, region, workspace, and account. Treat app counts as current marketing information, not as proof that a particular connector or action is available to you.
Controls that make delegated work reviewable
Use AI where language varies: summarizing, extracting details from prose, mapping varied descriptions to a controlled category, and drafting. Use deterministic rules for required fields, exact status transitions, thresholds, access checks, duplicate detection, and irreversible actions. For example, let Work propose a CRM update from an email, then have rules check the account ID, allowed status, required fields, and existing record state before an authorized person approves the change.
A proposed output contract might look like this. The fields are an external implementation design, not a Work-generated or vendor-published schema.
{
"source_id": "doc-123",
"source_url": "https://example.com/policy",
"source_timestamp": "2026-11-14T09:00:00Z",
"evidence_excerpt": "Illustrative source passage",
"proposed_action": "Draft summary for review",
"requires_human_review": true,
"idempotency_key": "source-system:item-id:version:destination:action"
}This example describes one observation or proposed action for a source item. It does not replace separate records for the task run, source item, citation, or aggregate.
Define the grain of each record before saving results:
task_run: one execution of a scheduled or manually initiated task.source_item: one retrieved document, message, pull request, file, or webpage.observation: one result for a particular source item or prompt.citation_record: one cited source passage or URL attached to an observation.aggregate_summary: a period-level rollup such as a daily, weekly, or monthly total.
Do not use a date alone as a deduplication key. A safer proposed key can combine source system, source item ID, source version, destination record, and action type. For an observation, use a run-specific observation ID. For a citation, use the observation ID plus a citation index or normalized URL. For an aggregate, include the account, period boundaries, aggregation definition, and model or engine where those dimensions affect the result.
Enforce uniqueness in the destination database or use an atomic upsert when concurrent writes are possible. A model instruction to “avoid duplicates” cannot enforce uniqueness, and lookup-then-create is not race-safe. These are external implementation controls, not features supplied automatically by ChatGPT Work or Zapier MCP.
- Confirm the source, destination, and record identities.
- Define required fields and deterministic validation rules.
- Verify that the action is within the authorized permission scope.
- Enforce a unique key or atomic upsert for replayed or concurrent events.
- Name the person who approves exceptions and consequential actions.
If a result is incomplete or uncertain, store it for review rather than triggering a write. A named owner should approve, correct, or reject it. Retries must check whether an approved action already happened. Teams designing bounded AI responsibilities and exception paths can learn more about AI agent implementation.
Limitations and security considerations
Access and integrations can be restricted, browser behavior varies, and output quality needs review. OpenAI identifies prompt injection, sensitive-data exposure, credential misuse, and unintended actions as agent risk scenarios. These are risks to manage, not claims that a particular incident occurred. Confirmations and permission controls reduce risk but do not eliminate it.
Webpages and documents may contain untrusted instructions. Treat retrieved content as evidence to evaluate, not as permission to change systems. Start with read-only or narrowly scoped access, use the minimum necessary files and accounts, and review high-impact changes before approval. Keep backups when local files could be modified.
Before distributing a report, presentation, spreadsheet, or other deliverable, check source accuracy, calculations, citations, formatting, permissions, file changes, and intended recipients. OpenAI’s agent security guidance and prompt-injection explanation describe these risks and safeguards.
Frequently asked questions
Is ChatGPT Work the same as Codex?
No. Work is intended for multi-step knowledge work such as research and deliverables. Codex is oriented toward software development, repositories, terminals, tests, and developer tools. The distinction is explained in OpenAI’s product documentation.
Can Work access files on my computer?
Desktop Work can access permitted local files. Cloud Work on web or mobile cannot directly read your computer’s files. Local access remains subject to permissions, operating-system support, rollout, and workspace settings.
Are local Work tasks fully offline?
Not necessarily. Local tasks run on the computer, but messages or task context may be stored in the cloud. Local tasks may also have different synchronization, scheduling, and sharing behavior from cloud chats.
Can Work sign in to websites?
The built-in desktop browser can support sign-in on documented surfaces. Browser sign-in and subsequent actions depend on the site, account, task, workspace policy, and required approvals. Enter credentials in the browser, not in chat.
Can a scheduled task use every event from a connected app?
No. Scheduled Tasks support documented schedules and some supported app events. Connecting an app does not make every event available. Check the task setup and current supported-task documentation.
Does connecting an app allow both reading and writing?
No. Read and write capabilities depend on the specific connector, action, account authorization, permission scope, plan, and workspace policy. Verify the exact action before relying on it.
How should I prevent duplicate updates?
Store a stable proposed idempotency key and enforce it with a destination-side unique constraint or transactional upsert. Include the source system, source item or event ID, source version, destination record, and action type where those values are available. Do not rely on a model instruction or a non-atomic lookup followed by create.