Local cloud maxxing

Your house, not a rented box

Did you know you can run a Cursor cloud agent on a machine that is already sitting in your house.

Not a rented sandbox. Not some anonymous box in a region you forgot you picked. Your machine. Your checkout. Your tools. The thinking still happens in Cursor's cloud. The hands, the terminal, the file edits, those happen on the hardware you already own.

I did this on 3 Sep 2026. From my phone.

I instructed Grok Bot. Cooper, in my case. Cooper launched a Cursor cloud agent onto my own hardware. The worker on that machine is named build365, no space, that is the name, write it like that. The agent opened a PR and merged a joke into a real repo, onto main. Phone, Grok Bot, Cursor cloud, my machine, main.

The joke that landed, because you are going to ask, was this:

Why did the concentrated liquidity pool go to therapy? Too much tick anxiety, not enough range.

It went on the end of the README. That was the test. One joke. Clean branch off origin/main. Ignore the other dirty files sitting in that checkout, I had lake work in there and I did not want the agent touching it. If the PR was clean, merge it. It was clean. It merged.

That is the whole story. Here is how you actually do it, because the story is cute and the setup is where people get stuck.

Cursor calls this My Machines. The docs are here:

https://cursor.com/docs/cloud-agent/self-hosted-guides/my-machines

https://cursor.com/docs/cloud-agent/self-hosted-guides/my-machines

Read those if you want the official version. I am going to talk through it the way I would talk through it if you were on the sofa.

The mental model is simple once it clicks, and it does not click until someone says it out loud. There is an agent loop in Cursor's cloud. That loop is the brain. It plans, it decides, it writes the next instruction. Then it sends tool calls down an outbound connection to a worker process on your machine. The worker runs the command. Edits the file. Comes back with the result. The brain takes another step.

Your machine opens that connection. Outbound HTTPS. Cursor does not punch a hole into your network. No inbound ports. No "please open 443 the other way." If you have been avoiding this because you did not want to become a sysadmin for a weekend, that is the bit that should relax you.

The worker has to stay running. It is long-lived. You start it, you leave it, you reuse it. If you kill the process, the machine disappears from the picker, which is obvious when you say it and annoying when you forget.

Name it, point it at a checkout, leave it running

Install the CLI first.

On macOS, Linux, and WSL:

Then check it actually landed:

If that command is not found, your PATH is lying to you. Fix that before you do anything clever.

Sign in.

Browser login is the easy path on a personal machine. That is what you want. There are API key and token options in the docs for headless boxes. I am not going to walk those here because I did not use them for this, and I am not going to invent a click path I did not take.

Then you start the worker. This is the line that matters, and the name matters.

Put your real checkout path in there. Not a placeholder forever. The name is build365. No space. Cursor matches on the name later, and a space in the name is how you spend twenty minutes talking to a picker that cannot see you.

You can give one worker more than one checkout. Repeat --worker-dir.

Cursor matches the git remote. That sentence is doing a lot of work, so I am going to say it again slower.

Each worker directory you pass has to exist. For each one that has a Git remote, the worker registers routing metadata. When a cloud agent wants to work on a repo, Cursor looks at that remote and tries to find a worker that is sitting in a checkout of that same repo. If you started the worker in your home folder, there is no useful remote, or the remote is not the repo you think it is, and Cursor will not match it. Starting in $HOME will not match a repo. I am telling you this because it is the exact way this fails, and it fails quietly until you notice the machine is not in the list you expected.

Point --worker-dir at the actual clone. The one with origin set to the GitHub repo you care about. In my case that was the repo checkout on build365.

Keep the worker process running. Then go to cursor.com/agents. The machine should show up in the environment dropdown. Send a task.

That is the documented path for running one. I did not go click around inventing extra screens. Phone to Grok Bot to a Cursor cloud agent pointed at that machine is what I actually did. Same worker. Same matching. The agent still has to land on a checkout that matches the remote.

Start with a joke, then treat it like a computer

Now the test, because you should not start with "rewrite my architecture."

Give it something stupid and small and obvious. I gave it a joke. One joke, at the end of the README. Branch off origin/main, clean. Do not scoop up the other dirty files. I had lake work sitting in that checkout. Local mess. The agent did not need it. If you do not say "ignore the other dirty files," some agents will try to be helpful and commit your laundry. Say it.

PR. Merge if it is clean.

That is a real test. You will know if the worker is on the right machine, if the remote matched, if the branch came off main, if it had the manners to leave your other work alone. If that works, you can trust it with something you actually care about. If that does not work, you have not lost anything except a joke.

The joke, again, because it is now on main and I am not going to pretend it is not:

Why did the concentrated liquidity pool go to therapy? Too much tick anxiety, not enough range.

If you work anywhere near concentrated liquidity you already hated that, which is the point.

A few things that will waste your afternoon if nobody warns you.

The name is an identifier. Use the same name every time you start the worker, or Cursor will treat it like a different machine. build365. Not build 365. Not Build365-new. Pick one string and stop touching it.

The worker directory is not "somewhere near the repo." It is the repo. Git remote. Origin. That is what gets matched. Two checkouts of two remotes on one machine is fine, you just pass --worker-dir twice. One checkout of the wrong remote is not fine. Cursor would rather reject the job than run it in the wrong tree, which is correct, and also the reason you will get a confusing failure if you pointed the worker at the cousin of the repo you meant.

If the machine does not appear in the picker, do the boring checks in order. Is the worker process still running. Are the Cursor app and the CLI on the same account. Does the worker directory have the git remote you think it has. Can the machine reach the outbound hosts. The docs list those. You do not need inbound anything.

There is a preflight for this.

It checks authentication, privacy routing, repo labels, and whether Cursor can see matching workers. You can also start with debug on:

Use it. Do not sit there refreshing the dropdown like the dropdown is the problem.

I am not going to write you a novel about Slack triggers and Linear labels. Those exist. worker= and machine= on Slack, GitHub, Linear, if you want a named machine from those surfaces. The docs cover it. That is not what I did from the phone. I am not going to dress it up like I did.

What I actually like about this, and this is the part I would want bookmarked, is the split.

Cloud is good at the loop. Your machine is good at being your machine. The repo is already there. The tools are already there. The weird local state you did not want to recreate in a fresh cloud environment is already there. You do not have to clone the world into a throwaway VM every time you want an agent to touch a file. You also do not have to sit at the desk. I was on my phone.

That last bit is the one that feels like a party trick until you have done it once. Then it just feels like a computer. You say a thing. A worker you named, on hardware you own, does the thing in a real checkout. If the change is a joke on a README, you laugh. If the change is a real patch, you review the PR like a person who still has a job.

I am going to say this plainly because it is the failure mode hiding under the party trick.

Do not start the worker in $HOME and hope Cursor figures it out. It matches remotes. Give it a checkout.

Do not give the worker a name with a space in it and then wonder why nothing finds build365.

Do not ask it to "just commit whatever is dirty." Tell it the branch, tell it origin/main, tell it to leave the other local work alone. I had lake files sitting there. They were not part of the joke. They did not go in the PR.

Do not kill the worker and then ask why the machine vanished from cursor.com/agents.

Do not invent a bunch of extra setup. Install the CLI. Login. Start the worker with a name and a worker-dir. Leave it running. Send a small task. Look at the PR.

If you want the longer official page, it is still this:

https://cursor.com/docs/cloud-agent/self-hosted-guides/my-machines

https://cursor.com/docs/cloud-agent/self-hosted-guides/my-machines

Install, login, start, name, worker-dir, git remote, outbound only, environment dropdown at cursor.com/agents. That is the path. The rest is taste.

My taste, today, was a joke on main, from a phone, through Grok Bot, onto a worker called build365.

Are you even local cloud maxxing.

You can instruct Grok bot from your phone to work in Cursor cloud on your own hardware and push a joke straight into main.

That is not a slogan I workshopped in a doc. That is what happened. The image on the tweet is the joke. The repo has it at the bottom of the README. The worker is still named build365.

If you try this, start with something you would not mind seeing on main. A joke is about the right size. Then you will know whether the brain in the cloud and the hands on your desk are actually talking to each other.

After that it is just a computer, which is the highest compliment I have for any of this.