Cursor 管理员强制全部走自托管
Cloud Agents 仪表盘 Self-Hosted：Allow 是按请求选择，Require 把每次 Cloud Agent 都打到你们的 worker。
cursor 管理员强制全部走自托管：在 Cloud Agents 仪表盘的 Self-Hosted 一节打开 Require Self-Hosted Machines。打开之后，Cloud Agent 跑到你们的工人上，而不是 Cursor 托管 VM。Allow Self-Hosted Machines 只是让用户按请求选择；没开 Allow，默认仍走托管。
两个开关不要当同一个
Allow：用户可以 opt-in。Slack 写 self_hosted=true、self_hosted、selfhosted 或 pool=<name> 才会进池。Allow 关着时，Slack 拒自托管 opt-in 并在频道里回复；Linear 给一条 agent activity 错误，让管理员打开自托管或拿掉提示，改走托管。
Require：每条 Cloud Agent 都进自托管。Slack 上每条 @Cursor 都走工人。例外是请求用 worker= / machine= 点名某台 My Machines，那条仍打到个人机，不进池排队。
池工人认领带标签。池请求都带 repo=<nwo>；命名池再带 pool=<name>。CLI 见 cursor cli 怎么用。
GitHub 公共仓有额外护栏
GitHub 上只有仓库 OWNER 和 COLLABORATOR 能把运行打到自托管。其他评论者即使写了 opt-in，也走托管；Require 打开则直接跳过。官方写明是为了保护公共仓，避免外部贡献者一条评论就把活送进内网工人。
Linear 不解析单独的 self_hosted=true，要用 pool=<name>、[pool=] 或父子标签。Slack 还认老别名 private_worker=true、useprivateworker。
国内团队若 Slack 还没接上 Cursor，先看 Slack 集成，再决定开 Require。Require 一开，频道里随手 @ 一下就会占工人。
没有空闲工人时请求就等着
池是持久对象。最后一台工人断开，池还在可选列表里，容量可以缩到零再拉起来。POST /v0/private-workers/pools 能在工人连上之前登记池；GET 看已连接和占用数；DELETE 是软删，不影响当前连着的机器。
Require 开了、池里没人认领，会话就停在队列。文档没写自动回落到托管。先 Allow、养一批稳定工人、看 GET 的 in-use，再切 Require。
个人试用别开 Require
一个人连笔记本验证流程，用 My Machines 加 Allow 即可。Require 面向「工具执行不许再进 Cursor 托管 VM」的企业策略。Team Pools 还要 Enterprise 和服务账号密钥，个人密钥起不了池工人。策略评审时把 GitHub 公共仓那条护栏写进变更说明，避免开 Require 后外部贡献者的 @cursoragent 全部被跳过却没人知道原因。