The session left the laptop

01The laptop closes; the task continues

Imagine an engineer preparing a client handover. She asks an agent to gather notes, compare a repository and draft the final document, then closes her laptop before leaving. This is a hypothetical task, not a run we performed. The important question is what continues after the lid shuts: computation, access to connected accounts, or the connection to a folder on that machine?

The releases of 17–21 August 2026 made that question harder to answer by looking at one terminal. Cursor introduced Origin code hosting, Anthropic made its Files API generally available, and Codex expanded control over existing sessions. A task could have a repository host, stored inputs and a resumable conversation with different owners and lifetimes. ^{1 4 6}

Cowork offers a concrete illustration of those separate lifetimes. Its help documentation, checked again for this October update, describes work continuing in the cloud with the laptop closed. Local folders require the desktop app to be open and the session to have started on desktop or be scheduled. That is a present-day explanation of the mechanism, not a reconstruction of every Cowork setting on 22 August. ²

02A sleeping computer is not a revoked account

For the handover task, losing the local folder might be inconvenient without ending the job. The agent could still have material already in its session and access through connected cloud applications. The engineer has stopped watching a screen; she has not necessarily withdrawn those grants. Conversely, a continuing session does not prove that the file it needs is still reachable. ²

Anthropic’s safety guide separates the isolated execution environment from the access granted through tools. Untrusted material becomes dangerous when the agent can both read it and take a consequential action. For our hypothetical handover, reading an external document and sending the finished package are different authorities. Giving both to one session creates a path that sandboxed computation alone does not close. ¹²

The approval mode matters along that path. The guide distinguishes automatic approval from skipping approvals, and recommends manual approval for sensitive work. It still requires a prompt before permanent file deletion. None of that means an engineer must approve every harmless step; it means the authority to send a client document should be a deliberate choice, rather than an accidental consequence of connecting the account. ¹²

03The uploaded file has another boundary

Now suppose the engineer builds a small API application to prepare handovers for several clients. That is a separate application design, not a claim about Cowork’s internal implementation. Moving its inputs into a file service changes the ownership question from “which laptop folder?” to “which caller can use this stored object?”

The 19 August release notes took the Claude Files API out of beta. Requests without the old beta header use the new response format, including expiration and list pagination; callers retaining the header keep the previous format. That transition establishes an API contract. It does not establish separation between the application’s customers. ⁴

The Files guide, reread for this update, defines access at workspace level. A key with access to a workspace can reach its uploaded files; a conversation or end-user identity does not create a narrower boundary. The guide says to retain user-to-file mappings server-side, reject untrusted file IDs and use a separate workspace for each tenant. Expiration is a separate decision, set at upload. ¹³

For the handover application, a file ID submitted by Client A cannot be accepted as proof that the file belongs to Client A. A successful request would show only that the application’s workspace key could access it. Authorization belongs in the mapping the application controls, before it sends that reference onward. Durable storage makes the document reusable; it also makes a mistaken sharing rule reusable.

04A second host can still have a first dependency

The repository side needs the same distinction. Cursor’s 17 August Origin announcement describes two paths: Origin-hosted repositories receive pushes directly, while synced GitHub repositories keep GitHub as their source of truth. Reviews synchronize in both directions for the synced path. Those are different dependency arrangements, even when they appear in the same editor. ¹

GitHub’s incident report for that day records elevated errors from 13:28 to 21:15 UTC. The original table below preserves the reported service timings and peak error rates. Cursor separately reported GitHub degradation affecting its services, including Origin. This establishes a failure affecting dependent services; it does not prove that every Origin-hosted repository needed GitHub for every operation. ^{10 11}

For the engineer’s handover, a visible repository in a second interface is therefore not enough to promise that a push or review can finish during a GitHub outage. The relevant fact is which host receives that operation. Native Origin hosting deserves a separate availability assessment from the GitHub-sync path, rather than inheriting either its weakness or an untested promise of independence.

05Resuming the conversation must restore its policy

The handover may continue from another surface or after a pause. Codex rust-v0.149.0, released on 20 August, added an agents dashboard and a queue for messages to existing sessions. Its release notes also say resumed and forked threads restore their permission profile instead of resetting to current defaults. That last detail matters more than the number of sessions visible in a dashboard. ⁶

A saved conversation and a restored permission profile solve different problems. The transcript tells the agent what work was under way. The profile says which actions the resumed process is allowed to take. A reviewer who sees the expected conversation cannot infer that the intended execution policy came back with it.

A useful pilot would pause the hypothetical handover, resume it through the real launcher and try a deliberately denied operation using disposable data. Record the selected policy and the resulting refusal beside the resumed output. This is a proposed check, not evidence that we exercised Codex or any particular deployment. It tests the transition on which the workflow relies.

06Hand over authority as carefully as the document

The engineer returning to the finished document needs more than a completion message. She needs to know which source revision was used, where the inputs came from and whether the session could send the result without another decision. Those details connect the artifact to the authority that produced it. A polished document alone cannot answer them.

For this workflow, the durable choices are modest: a dedicated working folder, narrowly selected account grants, a server-controlled file mapping and a permission profile that survives resume. They need not live in a large policy document. They need to match the actual path taken by the task, including the parts that continue after the laptop disappears.

Cloud execution can remove the requirement to keep a screen open. It does not remove local dependencies, tenant boundaries or review ownership. The August releases made those distinctions part of ordinary agent work. The payoff is a task that can continue without losing the meaning of the limits under which it started.