My Machines

My Machines 让 Cloud Agent 使用你已经有的机器：笔记本、devbox、远程 VM 或团队内网工作站。

1. 先判断

My Machines 适合“这台机器已经能跑项目”的场景。Cloud Agent 的推理和任务循环仍在 Cursor 云端，但文件编辑、终端命令、浏览器动作和工具调用会在你的机器上执行。

这解决的是三类问题：

不适合把它当成无状态云 runner。它依赖 worker 进程持续运行，也依赖 worker 所在目录的 git remote 正确匹配目标 repo。

2. 工作方式

worker 会从你的机器向 Cursor 发起 outbound connection。Cursor 云端 agent 通过这条连接下发 tool calls，你的机器执行实际操作。

flowchart TD
  User["Start agent from Web / Slack / GitHub / Linear"] --> Cloud["Cursor cloud agent loop"]
  Cloud --> Worker["Outbound connection to your worker"]
  Worker --> Repo["Local repo checkout"]
  Worker --> Tools["Terminal / editor / browser / MCP stdio tools"]
  Worker --> Artifacts["Optional artifacts upload"]
  Worker --> Result["Branch / logs / comments / dashboard result"]

这条链路没有入站端口、公开 IP 或 VPN tunnel 要求。如果你的公司网络只允许代理出站，worker 环境里设置 HTTPS_PROXY 或 https_proxy。

3. 快速启动

官方路径是先安装 agent CLI，再登录，再启动 worker。

# macOS, Linux, WSL
curl https://cursor.com/install -fsS | bash

# Windows PowerShell
irm 'https://cursor.com/install?win32=true' | iex

常用命令：

--auth-token-file 对 Kubernetes 或长期 devbox 更实用，因为挂载文件可以被轮换；环境变量通常在进程启动时固定。

4. 从聊天入口指定机器

Slack、GitHub、Linear 这些入口默认不一定知道你要用哪台机器。要指定 My Machines，使用 worker= 或 machine=。

Cursor 只有在三个条件同时成立时才会把任务路由到这台机器：

1. 机器属于触发请求的 Cursor 用户。
2. 机器的 --name 和请求中的 worker=<name> 或 machine=<name> 匹配。
3. 机器注册的 repo 与触发入口解析出的目标 repo 匹配。

repo 来源不是机器名，而是触发入口：

每台机器的注册 repo 来自启动 worker 的目录中的 git remote。要服务多个 repo，就在每个 repo checkout 里分别启动 worker。

5. 失败时不会乱跑

如果 worker=<name> 找到同名机器，但这台机器注册的是另一个 repo，Cursor 会拒绝任务，而不是把 repo A 的任务丢到 repo B 的 checkout。

如果没有机器同时匹配 linked user、machine name 和 target repo，请求也会失败，不会自动 fallback 到其他环境。

常见修复：

• 确认 GitHub / Slack / Linear 账号和 Cursor 用户已正确关联。
• 确认 worker 在目标 repo checkout 下启动。
• 确认 git remote 指向目标 repo。
• 确认机器名拼写一致。
• 用 agent worker start --debug 生成 preflight report，看认证、repo label 和可见 worker 状态。

self_hosted、pool= 和单独的 repo= 不会指定 My Machines。它们属于 Self-hosted Pool 路由；如果要用个人机器，必须配 worker= 或 machine=。

6. Artifacts 和网络

artifacts 行为与 Cursor-hosted agents 一致：agent 在 worker 内生成截图、视频或日志引用，再由 worker 通过 HTTPS 上传到 Cursor-managed storage。

worker 至少需要 outbound HTTPS 访问：

如果防火墙只支持 wildcard，*.s3.us-east-1.amazonaws.com 能覆盖 artifacts host，但会放开该 region 的其他 bucket。能配精确 host 时优先精确 host。

7. MCP 路由边界

My Machines 下 MCP 按 transport 分流：

如果 MCP server 必须访问私有网络，优先用 command / stdio，因为进程直接跑在 worker 机器上。HTTP MCP 则从 Cursor backend 发起连接，适合公开可达或已经有 OAuth 边界的服务。

本章自检

上线前至少回答这 4 个问题：

1. worker 是从哪个 repo checkout 启动的，git remote 是否匹配目标 repo？
2. 触发入口中是否显式写了 worker= 或 machine=？
3. 防火墙是否允许 api2.cursor.sh、api2direct.cursor.sh 和 artifact host？
4. artifacts、日志和 PR diff 中是否可能出现 secrets、客户数据或内网截图？

通过标准：你能让 Cloud Agent 在指定机器上跑一个真实任务，并能用 debug report、worker name、repo remote 和 PR 结果解释整条链路。

官方来源

• Cursor My Machines —— 官方 My Machines、worker 启动、worker routing、artifacts、networking 和 MCP 行为。
• Cursor Self-Hosted Pool —— 官方企业 worker pool 路由。
• Cursor Cloud Agent Security —— 官方 Cloud Agent 安全和网络边界。

接下来去哪