Cursor Cloud Agents Now Run on Machines You Manage — Where the Agent's Context Actually Lives (2026)

The one sentence that defines the split

From the announcement:

"With Self-Hosted Machines, only the execution environment moves while the agent loop, inference, and planning remain in the Cursor cloud. Tool outputs flow back to Cursor for inference and may contain code, and agent transcripts may be processed and stored by Cursor."

Three claims in one sentence. Execution moves. Tool outputs flow back and may contain code. Transcripts may be processed and stored.

The documentation says the same thing from the other direction, and it is worth reading both because the docs enumerate what travels:

"The full checkout, build cache, and machine-local credentials stay on your machine. During a run, the worker sends Cursor the content the agent needs, such as file contents, terminal output, diffs, screenshots, local MCP results, and routing metadata."

File contents is on that list. Not because Cursor is being cagey — they wrote it down plainly — but because inference needs the bytes the model is reasoning about. An architecture where the model runs elsewhere cannot avoid it.

The two halves have different retention rules

Cursor's cloud agent security page splits agent data into kinds and gives each its own retention rule. Two of them matter here.

The runtime workspace holds "The checked-out repository, build artifacts, and tool-execution context for a live run." Its retention: "Recycled automatically after the run goes idle; the timer refreshes when you send follow-up prompts."

The conversation state holds "Prompts, model responses, tool calls, diff context, and demo artifacts that make up the transcript." It lives in the "Cursor backend, encrypted with per-agent keys," and its retention is "Kept indefinitely by default so you can revisit and resume runs; deletable on demand."

So the durable record of what the agent thought is the half that does not move. Self-Hosted Machines relocates the ephemeral half.

The default that decides whether a follow-up remembers

Here is the part with an actual number on it. In pool configuration:

"Once a worker is matched to a request, Cursor forwards all agent tool calls directly to the machine. The connection has an idle timeout that defaults to 1 hour."

And when that timer fires:

"Once a worker times out, Cursor marks it as freed. The machine can reset and re-enter the pool. If a user restarts a chat that has disconnected from its machine, the chat reconnects to a fresh machine from the pool. Workspace state from the original machine does not carry over unless the pool uses hibernation."

Read that last clause twice. Your conversation survives — it is in the backend, kept indefinitely. Your workspace does not. The docs are direct about the cost: "a follow-up that arrives after the machine released reacquires from the pool: the agent lands on a fresh machine and may spend its first minutes reconstructing the workspace it already had."

Hibernation is the documented answer: snapshot the machine when it goes idle, restore it if a follow-up arrives inside the reconnect window, start "a worker with the same id before the window lapses." If the snapshot is gone, you release the claim and "a replacement machine can claim it."

Pools are not bound to repositories

One more design detail with a context consequence: "Pools are not tied to individual repositories. A request only needs to identify the pool, and any available worker can claim it. This lets one pool serve many repositories."

Efficient. It also means the machine that serves your next request is not, by default, the machine that has any history with your project.

It does move execution, and that is the point. Teams generally use it, per Cursor, when "Agent tool execution needs to happen inside their network, with direct access to source control, internal services, and code repositories," when agents need "custom hardware, such as GPUs or Macs for iOS development," or when the build pipeline is "difficult to package as a Cloud Agent build." Those are real constraints and this genuinely solves them.

It does not move the reasoning layer, and that is by design. Cursor runs "the agent loop, inference, and planning." Your worker "performs file edits and terminal commands. It also runs computer-use tools and local MCP servers."

It is not a Cursor peculiarity. The same shape shows up in Anthropic's self-hosted sandboxes for Managed Agents, documented in almost parallel language: self-hosting "keep[s] the orchestration on Anthropic's side but move[s] tool execution into infrastructure you control." And on the memory layer specifically: "The agent's skills and the contents of any memory stores attached to the session are stored by Anthropic and copied into your sandbox for the session; changes the agent makes to memory files sync back to the store." Anthropic even documents a hard edge — "Memory stores cannot be attached to sessions on self-hosted environments on Claude Platform on AWS." Two vendors, same architectural conclusion: self-hosting relocates the sandbox, not the memory. The mechanics of these hosted stores are worth understanding on their own terms, which is what Claude's agent memory stores covers.

It does not, on its own, change your privacy posture for the worse. Cloud Agents "run in Privacy Mode," and with it on "Cursor never trains on code accessed by Cloud Agents or on the prompts and responses their runs generate." There is a Delete Agent API that "removes an agent's conversation transcript and artifacts on demand," and Enterprise teams "can also cap conversation retention with retention policies." Runtime Secrets are "stripped from the transcript, tool output, and commits and never reach the model." These are meaningful controls and they are documented.

"Nothing leaves the network now." The most common reading, and the one Cursor's own sentence corrects: tool outputs flow back for inference and may contain code. What stays put is the checkout, the build cache, and machine-local credentials. That is a genuinely different and narrower claim than "nothing leaves."

"So the agent remembers more, because the machine is ours." Backwards, for pooled setups. Owning the machine does not extend the agent's memory; it introduces a release timer you now administer. Without hibernation, an idle-released machine means the next follow-up starts on fresh hardware.

"Hibernation is on." It is a pattern you implement, not a switch flipped for you: shorten the idle-release timeout, snapshot on idle, watch for the claimed-but-offline queue entry, restore before the window lapses. That is a controller you write and operate.

"The transcript is on our side now too." It is not. Conversation state sits in the Cursor backend, kept indefinitely by default. Deletable on demand, cappable by policy — but not relocated by Self-Hosted Machines.

"One pool, one project." Pools serve any repository. If you were counting on machine affinity to keep a warm workspace for a specific repo, that is not what a pool guarantees.

Step 1: Write down where each kind of state lives in your setup

Take fifteen minutes and produce a four-line table for your own deployment. Cursor's docs give you three of the lines; the fourth is yours.

Checkout, build cache, machine-local credentials — your machine, gone when the worker resets. Runtime workspace — your machine, recycled after idle. Conversation transcript — Cursor backend, indefinite by default. Durable project knowledge — this is the line most teams cannot fill in, because the answer is "in whichever transcript happened to contain it."

That fourth line is the whole problem. Everything above it is either ephemeral by design or held by your vendor.

Step 2: Set the timers deliberately, then verify one release

Two knobs, and their interaction is what bites. Configure the worker connection's idle timeout with intent rather than inheriting the one-hour default, and decide explicitly whether the pool uses hibernation.

Then test the case you actually care about. Start an agent, let it build real workspace state, wait past the idle timeout, and send a follow-up. Watch whether the agent resumes or spends its first minutes reconstructing. Do it once and you will know which behavior your pool has, which is worth more than any inference from the docs.

While you are there, check that your controller handles the offline path. Cursor advertises a follow-up for an offline machine as a claimed-but-offline queue entry with claimedWorkerId and wakeTimeoutMs, and emits a matching event. If nothing in your infrastructure is watching for that, hibernation is not really configured.

Step 3: Put the knowledge that must survive outside every machine and every transcript

Steps 1 and 2 get you an accurate map and predictable timers. They do not answer the question underneath: when a fresh worker claims your follow-up, how does the agent know your conventions?

Today the answer is "from the transcript, if it is in there." That makes durable knowledge a byproduct of conversation history — held by your vendor, indefinite by default, and organized by session rather than by subject. It is a poor filing system for facts that should be true on every run, and the same reasoning applies to any stateless execution layer, which is why memory for MCP tasks lands on the same conclusion.

A separate memory layer removes the machine from the question entirely. Whichever worker claims the request, in whichever pool, on whichever repository, the agent reads the same store. Hibernation stops being the thing standing between a follow-up and a competent answer, and becomes what it should be — a cost optimization for workspace warmth. MemoryLake sets up in three steps.

Step 1: Create an API key

Sign in and generate an API key from your dashboard. The credential is bound to you rather than to a worker, a pool, or a machine image — which is the property that matters when the machine answering your next prompt is one your controller started ninety seconds ago.

Step 2: Upload your first memories

Put in what a fresh worker has no way to reconstruct from a checkout: architectural decisions and the reasons behind them, deployment conventions, the internal services an agent is allowed to touch, the corrections you have already typed into three different sessions.

Leave the ephemeral things ephemeral. Build caches and checkouts should be recycled; that is not a loss.

Step 3: Connect your AI & agents

Point your agents at the store. A pooled request then arrives with the project knowledge already in hand, and reconstructing a workspace costs you minutes of build time instead of a re-explanation.

The first change is that pool tuning becomes an economic decision instead of a knowledge decision. Right now, shortening an idle timeout to save money also shortens what the agent knows. Those should not be the same lever.

The second is that the cross-repository pool becomes safe to use as designed. One pool serving many repositories is efficient precisely because workers are interchangeable — and interchangeable workers are only a problem when the worker is where the knowledge lives.

The third is that your durable knowledge stops being a derivative of retention policy. Capping conversation retention is good governance; it should not quietly reduce what your agents understand about your codebase. Keeping the two separate is the same principle behind sharing one memory across tools rather than per-product.

• Quote the actual boundary, not the summary. Execution moves; the agent loop, inference, and planning stay in the Cursor cloud, and tool outputs flow back for inference.
• Set the idle timeout on purpose. The connection default is one hour. Decide whether that matches how your team sends follow-ups.
• Treat hibernation as infrastructure you operate. Snapshot on idle, watch for claimed-but-offline entries, restore with the same worker id inside the window.
• Do not rely on machine affinity. Pools are not tied to repositories; any available worker can claim a request.
• Use the retention controls that exist. Delete Agent API for a specific transcript, Enterprise retention policies for a window, Runtime Secrets to keep values out of transcripts and commits entirely.
• Keep Privacy Mode standard, org-wide. Legacy Privacy Mode is not supported for Cloud Agents, and the docs recommend enforcing the standard mode so every run inherits its guarantees.
• Audit what a fresh worker knows. If the answer depends on which transcript is attached, that knowledge is not durable yet.
• Re-check after changes. This shipped on September 2, 2026, with sandbox-provider integrations and Linux computer use arriving alongside it. Fast-moving surfaces move.

Self-Hosted Machines is a real answer to a real constraint, and Cursor documented its boundaries more carefully than the coverage around it did. Execution moves into your network. The agent loop, the inference, and the transcript do not.

The practical consequence is narrower than the headlines and more useful: in a pooled deployment, an infrastructure timeout now helps decide whether your agent starts a follow-up informed or from scratch. Set that timer deliberately, implement hibernation if workspace warmth matters, and keep the knowledge that must survive every release in a layer that no worker owns.