Cursor Self-Hosted Machines Run Agents Locally

The September 2, 2026 @cursor changelog from Cursor, Anysphere’s AI code editor, adds self-hosted machines for running agent tool calls on infrastructure you control. A Cursor self-hosted machine is a worker that lets Cursor agents execute tools on your laptop, VM, pool, or sandbox instead of a hosted worker. It deals with the annoying gap between useful unattended agents and the very real fact that code, build outputs, and secrets often live behind your network boundary. The takeaway: keep the agent near the build, then use Cursor rules and reviewable IDE workflows to make that local power boring in the best way.

Keep tool execution where the repo already works

The headline change is simple: Cursor agents can now run tool calls on self-hosted machines. Your codebase, build outputs, and secrets stay on machines in your infrastructure while the agent drives the work from Cursor.

That matters because many repos are not portable. A frontend may need an internal package registry, a mobile build may need signing material, and a backend may depend on a private database snapshot that should not leave the network.

The trap is assuming self-hosted means safe by default. It means the execution location changes. You still need a repo boundary, a clean working tree, and a way to review what the agent changed before anything lands.

A very normal first job is dependency cleanup. Let the agent run the package manager, update a lockfile, run tests, and open the diff in Cursor. Do not start with a database migration that can touch production-like state.

Use pools when one laptop is too personal

Cursor describes two shapes in the changelog. My Machines connects a single laptop or VM to your account for personal workflows. Team pools are named queues of workers where any available machine can claim the next request.

The interesting detail is that pools are not tied to one repository. You name the pool, and workers can pick up work as requests arrive. Capacity can grow when more workers connect and shrink when they disconnect.

That sounds small until you have three long-running prompts queued behind one developer’s laptop. A named pool turns local agent work into a shared runtime without pretending every repo needs its own special snowflake machine.

The trap is noisy capacity. If every worker has a slightly different Node version, browser package, or private CLI setup, the agent will fail in ways that look like reasoning errors but are really environment drift. Treat a worker image like you would treat CI: boring, named, and repeatable.

Cursor also notes that pools can hibernate idle machines and restore within a reconnect window when follow-up work arrives. That is a practical nod to cost. You should not have to keep an expensive desktop or sandbox hot just because the next prompt might show up.

Watch the desktop without pretending it is magic

Self-hosted workers now support computer use on Linux and Mac. With the right desktop packages, an agent can click, type, take screenshots, and drive a browser. Cursor also says you can watch the desktop or take control from Cursor.

This is the part that feels most like how developers actually debug. Some tasks are not just shell commands. They involve a browser login, a flaky Storybook page, a visual regression, or a local app that only reveals the bug after three clicks.

The trap is giving a desktop agent too much trust. Clicking is still tool execution. Screenshots can expose private data. Browser sessions can hold credentials. If you would not let an intern poke around an admin console unsupervised, do not let an agent do it just because the pointer moves by itself.

A good fit is a local UI reproduction: start the app, open the failing route, capture the screenshot, inspect console output, and propose the fix. A bad fit is a broad prompt like fix the checkout flow while logged into a real payment sandbox with write privileges.

This also explains why stories like Git Hijack Lets Repos Run Code in Agents keep mattering. Local execution is powerful because it is close to the repo. It is risky for the same reason.

Try it on one boring job first

Start with a small experiment where failure is cheap. Pick a repo that already runs locally, has tests, and does not need production credentials. Ask Cursor to do a narrow maintenance task on a self-hosted machine, then review the diff in the IDE before you commit.

Use a lightweight Cursor rule to make the boundary explicit. Put it near the repo work it protects, not in someone’s memory or a chat prompt that disappears.

# .cursor/rules/self-hosted-agent.mdc
---
description: Keep Cursor agent work on self-hosted machines inside the safe repo boundary.
alwaysApply: true
---

- Do not read files outside this repository unless I explicitly ask.
- Do not use production credentials, tokens, or customer data.
- Prefer read-only commands before write commands.
- Before editing, summarize the planned files and commands.
- After editing, show the diff, test command, and any command that failed.

Copyable safe-run checklist:

• Use a clean branch with no unrelated local changes.
• Pick one command the repo already knows, such as npm test, pnpm test, cargo test, or pytest.
• Give the agent one task: update a fixture, fix one failing test, or reproduce one UI bug.
• Watch the first run if desktop computer use is enabled.
• Review the diff in Cursor before committing.
• Delete or rotate any token that accidentally appears in logs.

The gotcha is that self-hosted workers inherit local mess. If your laptop has a magic environment variable, stale build cache, or uncommitted file that CI lacks, the agent may succeed locally and fail everywhere else.

Put subagents and skills near the runtime boundary

Self-hosted machines are mostly a runtime story, but they touch how Cursor subagents and skills should be written. A skill that says run the internal smoke test is much more useful when the worker can actually reach the internal service. A custom subagent that reviews infrastructure diffs is less fragile when its tools run in the same network as the repo’s validation scripts.

This is where Cursor subagents and skills stop feeling like abstract prompt organization. They become small operating habits: which agent gets the task, which skill contains the workflow, and which rule keeps the worker from wandering into places it should not go.

The trap is packing runtime assumptions into the skill description. Do not make a cursor skill silently depend on one person’s laptop. Put the environment expectation in the repo rule or setup note: this smoke test needs the self-hosted pool named web-sandbox, and it should not run outside that boundary.

At Cursor Workshop, the useful pattern is plain: rules hold the boundary, skills hold reusable steps, subagents hold role-specific judgment, and the self-hosted machine supplies the place where tools can actually run.

Common questions

• Do self-hosted machines mean Cursor never sees my code?

  No, do not read the feature that broadly without checking your exact configuration. The changelog’s concrete claim is that tool execution can stay in your network, with the codebase, build outputs, and secrets on internal machines. That is different from a full privacy architecture statement for every prompt, model, or integration path.

• What is the difference between My Machines and team pools?

  My Machines is the single-worker path for a laptop or VM connected to your account. Team pools are named queues of workers that can claim requests as capacity appears. The useful distinction is operational: one personal machine is simple, while a pool helps when unattended agent work should not depend on one developer’s open laptop.

• Can a Cursor self-hosted worker use a browser or desktop?

  Yes, as of the September 2026 changelog, self-hosted workers support computer use on Linux and Mac. With the right desktop packages, an agent can click, type, take screenshots, and operate a browser. The caveat is that desktop sessions can expose private data, so watch the first runs and keep credentials scoped.

• Where do Cursor subagents and skills fit with self-hosted machines?

  Cursor subagents and skills define how work gets done; self-hosted machines define where the tools run. A good pairing is a skill for a repeatable smoke test, a subagent for focused review, and a repo rule that names the allowed worker boundary. Keep local environment assumptions visible so another worker can reproduce the run.

Best ways to use this research

• Best for: understanding why Cursor’s self-hosted machines are a local runtime feature, not just another agent setting.
• Best first artifact: a repo-scoped .mdc rule that limits file access, credentials, commands, and review expectations before the first self-hosted run.
• Best comparison angle: compare My Machines against named pools by asking one question: should this job depend on one personal machine, or can any prepared worker claim it?
• Best safety habit: start with maintenance work that already has a test command, then only expand to browser or desktop use after you have watched a full run.

Further reading

• @cursor — source
• Cursor — Agent
• Cursor — Rules

Next step

Pick one repo with a reliable test command and write the tiny .mdc boundary before connecting a self-hosted worker. Then ask Cursor for one boring fix and judge the feature by the diff, not the demo.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.