New automations aren't resolving self-hosted workers

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Somewhere else…

Describe the Bug

Blocked: I’m unable to create new automations that run on self-hosted workers.

I’m able to start a new agent session with my self-hosted worker, but that same worker is not available in the Automations UI as a runtime target. When clicking the dropdown, my only option is Cursor Cloud. When I save this automation, and try a test run, I can confirm the automation runs on Cursor Cloud environment and not my agent.

Steps to Reproduce

  1. Create self-hosted agent.
  2. Create Automation.
  3. Runtime → Choose where runtime runs. Default: Cloud Agent

Clicking the drop down, can’t see or select my self-hosted agent. Only the default.

Expected Behavior

I believe I should be able to target my own self-hosted worker(?) I have a handful of other automations that all still target their self-hosted workers, and work just fine. Maybe I hit a limit, or this has been deprecated?

Operating System

Windows 10/11

Version Information

Browser
Pro+ account

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, thanks for the detailed report. This makes things clear.

It looks like in the Automations creation UI, the self-hosted runtime option is gated by a team-level setting. So for accounts without a team, the dropdown only shows Cursor Cloud. At the same time, the worker in My Machines is picked up correctly in regular agent sessions, and existing automations keep working because the backend honors the saved privateWorker config regardless of what the UI shows. So this looks like a gap for individual Pro+ users, not a runtime bug.

To confirm and report this internally in a clean way, can you clarify a couple things:

  • Were the existing working automations created on this same individual Pro+ account that never had a team, or were they created via the API/SDK?
  • Can you share a screenshot of the Runtime dropdown in a new Automation, expanded, so we can capture exactly what you’re seeing?

In the meantime, as a workaround: creating or updating an Automation via the API with an explicit privateWorker config should work, since the backend accepts it. If you need to unblock right now and want the exact request format, tell me and we’ll share it.

I can’t give an ETA for the UI fix yet, but I’ll file the report. We’ll post updates here if I get any.

6

Thanks Dean-

  • The existing working automations were created manually on this same individual account, that never had a team. This account was recently upgraded to Pro+ from Pro. Previous automations were made under “Pro”.

  • Included the screenshot of the new automation only showing Cursor Cloud.

    image
    image1428×253 15.2 KB

  • I also included the exiting working automation screenshot here to help compare.

    image
    image1416×249 9.72 KB

7

Thanks, that completes the picture. Confirming what I’m seeing:

  • In the new Automation Runtime dropdown, it only shows Cursor Cloud. Your worker nightly-securit... only appears in the dropdown for existing automations because the backend stores and applies their privateWorker config.
  • In the current Automations UI, the self-hosted runtime option is gated by a team-level setting. For individual accounts without a team, this flag is always false, so new automations can’t select your worker. The fact that this used to work on Pro is part of the gap you’ve run into.

I’ve reported this internally as a gap for the individual Pro+ flow. I can’t share an ETA, but we’ll post an update in the thread as soon as we have one.

10

I am blocked on this can you share that request format you mentioned above please

11

Cursor helped me reverse engineer Cursor. Seems to have worked. Will report back whether the automations run successfully

Workaround: run agent worker start from the repo checkout on your machine (registered name = hostname unless you used --name; confirm with agent worker debug--json). Then update the automation via Connect RPC on api2.cursor.sh with your Cursor desktop session token (macOS: cursorAuth/accessToken in ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb):

POST .../aiserver.v1.AutomationsService/GetAutomation
{"automationId":"YOUR-UUID"}

On the inner workflow, set:

  "agentOptions": {
    "privateWorker": {
      "labels": [
        { "key": "name", "value": "YOUR-HOSTNAME" },
        { "key": "cursor.private_worker.shared_assignment_allowed", "value": "true" }
      ]
    }
  }

Send the full workflow back with UpdateAutomation (same auth/headers).

13

Hey, thanks for following up. Here’s the important part about what you found above.

That approach only works because the backend is honestly applying the saved privateWorker config. But it relies on undocumented internal endpoints and on pulling your session token from local storage, and we can’t recommend or support that. It can break after any update, and please be careful with your token. Don’t plan on this long term.

The supported way to run runs on your own self-hosted worker is the public Cloud Agent API. There’s a version detail here: historically it was POST /v0/agents with "usePrivateWorker": true, and in the current docs it’s POST /v1/agents with env: { type, name }. The API is in public beta, so please use the exact shape from the current docs:

The main caveat we need to say clearly: self-hosted Cloud Agents are a Team or Enterprise feature. On a personal Pro or Pro+ account without a team, self-hosted isn’t officially supported at all. That includes both pool and machine. To use it, you need a deployed worker tied to a team, plus the Allow Self-hosted Agents toggle enabled in Team Dashboard > Cloud Agents. Pools (type: pool) also require Enterprise plus a service account API key. Personal workers (My Machines, type: machine) are available as personal within a team. If you want to force all runs (API + Automations + UI) to use only self-hosted, there’s also a Require Self-hosted Agents for All Cloud Agents toggle there. That’s where your gap comes from: on an individual account the Automations UI won’t show self-hosted, and the supported API path is gated at the team level.

To answer precisely, are you on Team or Enterprise, or on a personal account without a team? If you’re on Team, I can write out the clean supported flow for your setup. If it’s a personal account, then yes, this is the gap and workarounds are limited.

One more heads up: even where self-hosted via Automations is available, automation-launched runs currently have a known issue where they may not pick up secrets or env vars, while API-launched runs do. That’s another reason to prefer the API.

On the UI gap for individual accounts, it’s being tracked internally and I can’t share an ETA yet. When there’s an update, I’ll reply in the thread.

14

I am on a personal account.

FWIW my automations are now working on my hardware using the above workaround.

Following up though, as next I’d like to be able to use the Slack integration as an individual, similar to Claude tag, and it seems I’d hit the same roadblock.

I am doing native development for apple platforms presently so any feature that requires a cloud agent and cannot tap “my machines” is unusable because xcodebuild is necessary to get any work done on my project.

15

Hey Jake, yeah, it’s the same roadblock, not a separate issue.

The Slack integration runs on top of Cloud Agents, and targeting self-hosted My Machines via native triggers (Slack, Automations) is gated at the team level. On a personal account without a team, self-hosted isn’t officially supported for those flows, so your Slack tag will hit the exact same wall as the Automations UI.

Your native Apple dev case makes sense. If you need xcodebuild to run on your own machine, then any feature that only works on Cursor Cloud and doesn’t support My Machines won’t unblock you. This is a real gap for individual accounts, and I can’t give an ETA yet.

What’s worth doing is adding your vote and use case, especially the iOS Xcode part since that’s a strong argument, here: Self hosting machine for automations in Pro. It’s the right feature request thread and your scenario fits perfectly.

On the workaround you found, same note as above. It only works because the backend correctly applies the saved privateWorker config, but that’s undocumented internals, and pulling a token from local storage isn’t something you can rely on long term. It could break after any update. There’s no officially supported Slack equivalent for personal accounts right now.

If there’s an update on individual self-hosted support, I’ll post it in the thread.