Cloud or local? Where your dot actually works
The location of the work determines its dependencies. A laptop going offline should be a planned condition, not a surprise.
Separate coordination from execution
A dot can coordinate work in the cloud while a particular task uses a connected local computer. That means the place you send a message does not necessarily tell you where the files, software, or browser session reside. Before assigning recurring work, identify the execution location for each step. A cloud research task and a local workbook task have different dependencies even when one conversation coordinates both.
OpenAI documents a cloud computer with its own files, software, and browser sessions. It can support work while your personal computer is off. Connecting your own computer adds access to its local resources under the applicable permissions. Local work requires that device to remain online with the ChatGPT app open. Treat that requirement as part of the workflow specification, alongside the input source and output destination.
Map the workflow by resource
Create a short resource table before deciding where the work belongs. List each source, its authoritative location, the account used to reach it, and whether the task requires local software. Add the destination for accepted outputs. This often reveals that only one step depends on a personal device, or that a supposedly simple workflow actually crosses several identity and network boundaries.
Consider an illustrative estimating review. Approved drawings may be in a cloud document service, a price schedule may sit in a local workbook, and the accepted estimate may belong in a project system. Research can potentially run in the cloud, while the workbook operation depends on the connected computer. The final review should identify which versions were used. Do not assume that cloud coordination makes every source continuously available.
Browser sessions do not transfer automatically
A signed-in personal browser is separate from the dot's cloud browser. Logging into a service on your laptop does not sign the cloud computer into it. OpenAI provides a private sign-in flow and a browser takeover option. Use those supported routes when needed. Credentials should not become ordinary chat content or be placed in a shared workflow document for convenience.
Website sessions can remain active until sign-out or expiration. A saved login and an active session are different states. The documentation says using a saved login for a new sign-in requires confirmation. Your operating procedure should distinguish a source permission problem, an expired session, and a service that blocks cloud browsers. Repeated retries are a poor substitute for identifying which dependency failed.
Plan local availability explicitly
A personal computer being offline does not mean its connection has been revoked. It means the resource is currently unavailable. If an assignment depends on that resource, specify whether the dot should wait, ask the owner, produce a partial draft with a clear limitation, or stop. Choose this behavior according to the cost of delay and the consequence of using incomplete information.
For overnight work, ask whether the organization can actually maintain the necessary local availability. Power settings, app closure, network changes, and employee travel can all affect the practical workflow. These are operational questions to verify in the intended environment, not promises made by an implementation slide. If dependable timing is essential, consider whether an approved cloud-accessible source or a different integration architecture is appropriate.
Know what happens to an existing task
The tasks documentation states that changing the selected computer does not move an existing task to that computer. Inspect the task's original environment and artifacts before redirecting work. A task-specific handover should include its location, accepted outputs, pending changes, and instructions. Otherwise a new task may recreate an outdated version or leave work stranded on the original device.
For coding assignments, a prepared Codex cloud environment is another distinct option. Repository access and environment setup belong to that environment. Do not interpret a dots connection as automatic access to every repository or conversation. The useful acceptance check is concrete: can the intended task reach its authorized files, run the necessary software, and leave results where the reviewer expects them?
Respect workspace and network boundaries
Enterprise policy can further constrain computer access. The admin guide notes that local sign-in, VPN access, and device policies do not automatically extend to the cloud computer. It also documents a specific residency-policy condition that can make local access unavailable. IT should evaluate the applicable configuration directly. A general cloud-versus-local diagram cannot settle a particular organization's residency or network requirements.
Before approval, test one normal run and one unavailable-resource run in the intended environment. Record the task location and the visible failure behavior. Confirm that output is preserved and that another authorized person can find it. The resulting map should tell an operator where to look when a job stops, which account to reconnect, and whether rerunning could duplicate an action. That is the foundation for dependable ongoing work.
The source record
Sources & editorial notes
Primary documentation checked September 29, 2026. Our implementation recommendations are editorial analysis. Illustrative workflows are proposed examples, not completed client case studies or performance claims.
- Connect computers and apps to your dot OpenAI
- Tasks and memory OpenAI
- Manage dots permissions and capabilities OpenAI
- ChatGPT Work Cloud security OpenAI
Found something that needs updating? Contact the editorial team with the passage and a supporting source.