A companion to Close the Lid
The Desktop Advantage
Your AI can understand the work and still be unable to reach it. The sandbox explains why.
Give an assistant a spreadsheet, and it can analyze a spreadsheet. Give it a properly scoped route into your working environment, and it can begin to participate in the work around that spreadsheet: the source files, the application that opens it, the browser where the result belongs, and the next revision.
That is the desktop advantage. Less carrying things back and forth. Less rebuilding the environment inside somebody else’s computer. More opportunity to complete the last step.
In Close the Lid, I made the financial case for controlling where scheduled work runs. This is the technical companion. Before choosing Claude Cowork or OpenAI’s ChatGPT Work on desktop versus cloud, ask a more useful question: Where does each action execute, and what can that action actually reach?
“Sandbox” names several different walls.
A sandbox is a restricted execution environment. It defines the resources a process can see and the operations it can perform. Its limits can include filesystem paths, process visibility, system calls, network destinations, device access, and resource budgets.
A container may isolate processes while sharing the host’s kernel. A virtual machine supplies a separate guest operating system. A userspace kernel such as gVisor intercepts application system calls and implements a Linux-compatible interface between the workload and the host. These are different mechanisms with different compatibility and isolation properties. gVisor explicitly warns that it does not implement every system call or every interface under /proc and /sys. Software that expects those interfaces can fail even when its code is correct. [4]
Above that sits another boundary: what tools the product exposes. The operating system might permit an operation that the assistant has no tool to request. Above that sit account permissions and application policy. A successful task needs a usable path through all of them.
“Try harder” cannot mount an absent folder, supply an unavailable application, or grant an OAuth scope. Sometimes the model is confused. Sometimes the door really is locked.
An uploaded file is a copy of a moment.
Suppose a project has a workbook, a folder of photographs, a brand guide, and yesterday’s exports. Uploading the workbook alone does not reproduce that environment. Uploading everything reproduces a snapshot that you must keep synchronized.
Direct access to a selected local folder can remove that handoff. Cowork’s desktop documentation describes reading and writing local files without manual uploads and downloads. ChatGPT Work supports local folders on desktop when the account and workspace permit it; its web and mobile experience cannot directly access your computer’s files. [5] [2]
The technical limit is the filesystem namespace: the set of paths visible to the process. /Users/you/Project on your Mac is not a location on a remote Linux machine. A mount or a mediated file tool must provide the connection. Even on your own laptop, a VM cannot simply see every host directory.
The practical gain is continuity. Ask the assistant to read the current inputs, write a new output alongside them, and compare the result with the previous version. Keep source material and outputs distinct, and use version history or backups. Local access reduces transfers; it does not resolve simultaneous edits or make overwrites reversible by itself.
Making the file is only part of finishing it.
A library that writes a presentation is not PowerPoint. A package that manipulates workbook cells is not the complete Excel application. A generated document may still need its actual application to recalculate, render, refresh an external connection, run a supported add-in, or expose a feature the library never implemented.
That is where desktop access becomes particularly useful: the assistant may be able to open the output in the application you will use, inspect it there, and correct the result. Think of a training deck whose text fits in the generated file but clips when opened with your installed fonts. The useful endpoint is the checked deck.
Cowork documents a sequence of connectors first, browser next, and screen interaction when needed. Supported computer use can operate desktop applications after permission is granted, though availability varies and screen interaction is slower and more error-prone than a direct connector. [6]
Do not confuse a local shell with a local application. In Anthropic’s documented local Cowork design, generated code remains isolated in a Linux VM; the host-side agent and approved tools provide other access. A Mac application does not become a Linux executable because both are on the same laptop. Desktop value comes from the available integration, not proximity alone. [7]
Your browser session lives somewhere.
OpenAI’s cloud browser is a browser on a separate remote computer. It has its own sessions and does not inherit the accounts already signed in on your device. You sign in separately. Those remote sessions may persist, but some websites and transaction steps remain unsupported. [8]
This matters when a task depends on a specific signed-in browser. A supported integration with that browser can reduce repeated authentication and manual transfers. A new browser embedded in a desktop app can still have its own profile, so “local browser” does not guarantee your existing cookies are present.
Network location creates a similar distinction. localhost means the machine or network namespace making the request. From a cloud process, it does not mean your laptop. A preview server on your computer, a private DNS name, or a service reached through your company VPN may have no route from the remote environment.
For Cowork’s cloud sandbox, Anthropic explicitly blocks private and internal address ranges and enforces outbound access through a mandatory proxy with allowed destinations. The agent cannot reconfigure that proxy. Local resources are reached through the approved desktop bridge instead. [1]
Even locally, check which tool makes the request. A server-side fetch does not borrow your laptop’s VPN merely because you clicked its button on the laptop. A VM also has its own networking configuration. The gain is the possibility of an authorized local route; the route must actually exist.
Explore the distinction
Where are the hands?
Choose an arrangement. These describe access patterns, not identical feature bundles across vendors.
Cowork’s surface guide documents the desktop bridge and its conditions. [3]
A saved conversation is not a running computer.
There are several kinds of persistence: messages, account files, browser authentication, a writable workspace, installed packages, and running processes. Saving one says nothing about the others.
Anthropic describes a fresh temporary sandbox for each cloud Cowork session, destroyed when that session ends. Account-level sessions and saved files are a separate layer. A saved output can survive the execution environment that created it. [1]
A local project directory gives you a durable place for inputs, outputs, instructions, and intermediate work. That can make iterative projects easier to resume and inspect. It does not guarantee that a VM’s installed packages, a background process, or the model’s working context will survive a restart. Put anything needed for the next run in an explicitly persistent location.
Resource ceilings also matter: memory, disk space, CPU allocation, execution time, available packages, and device access. But “cloud” does not imply one universal quota, and “desktop” does not imply unlimited resources or GPU access. I found no basis in the cited Work documentation for assigning its sandbox a particular memory limit, timeout, or kernel implementation. Those numbers would be guesses.
For a large or specialized workflow, test a representative input. Measure whether it finishes, whether it can install or use the required dependency, and whether the result survives the session. Buying a more capable model cannot remove a platform resource ceiling.
The desktop can do more because it can touch more.
That is a capability advantage and a responsibility. Anthropic states that its desktop computer-use path has no sandbox between Claude and the applications it operates. Per-app permissions and safeguards still exist; the separate VM used for generated code does not contain the effects of a click in an authorized application. [6]
Likewise, a read-only filesystem does not make an email connector read-only. Network restrictions on one tool do not automatically restrict every connector. Cowork specifically distinguishes its egress settings from web search, web fetch, and MCP routes. Audit the capabilities separately. [5]
The useful configuration is a deliberately sufficient one: the project folder, the needed application, and the appropriate connector permissions. Disabling approvals is not the same operation as expanding a filesystem mount or enabling a tool. Approval policy, technical access, and model safeguards are different controls.
Local execution also does not mean offline inference or that task data never leaves the machine. OpenAI expressly says messages and task context may be stored in the cloud even when Work runs locally. Treat execution location and data handling as separate questions. [2]
Choose by the last step
Put the assistant where it can finish.
If the job is remote research using connected sources and a remotely saved report, cloud execution can be the right fit. It avoids dependence on the laptop staying awake. OpenAI’s cloud browser explicitly supports continuing while the computer is closed, pausing when input, sign-in, or confirmation is needed. [8]
If the job is organizing a local archive, revising an ongoing folder of work, checking an output in a desktop application, or using a permitted local environment, start with desktop access. Where true local execution is available, it also puts that execution under the machine’s availability. Where the session runs in the cloud, understand exactly what the desktop bridge supplies.
My recommendation is simple: identify the final artifact, its destination, and the application that proves it works. Then choose the environment that can reach all three with the least manual carrying.
Intelligence is what the assistant brings.
Access is what lets it get the work done.