GitHub 官方说明，临时自托管 Runner 一次只接收一个 Job；这不等于底层 Mac 已自动销毁或重置。官方 Runner 参考 先按代码信任度选生命周期：只跑受信任私有仓库、权限受限且能核验清理时，可用受控常驻 Mac；外部代码或高权限凭据进入流程时，优先用每项任务后销毁的隔离环境。本周先检查触发事件、Runner 访问范围和签名凭据，不要把“删掉工作目录”当成安全隔离。

谁该看：独立开发者，正在权衡 iOS 构建机的维护复杂度与复用需求。
小型团队，需要把日常构建和签名发布分开。
发布自动化维护者，正在评估 Runner 上的凭据与任务残留风险。

01

先区分 Runner 在线与工作区干净

自托管 Runner 可以持续在线并重复领取任务；它的工作目录、缓存和主机上的其他状态也可能持续存在。Runner 进程显示为在线，只能证明它能接单，不能证明前一个 Job 留下的文件或系统状态已清除。GitHub 也明确提示，自托管 Runner 不保证每项任务都运行在干净的临时虚拟机中，不受信任代码可能持续影响执行环境。自托管 Runner 安全使用说明

你要分别核验两件事：

  • 在线状态：Runner 是否已注册、是否在线、最近处理了哪些 Job。看 Runner 页面和 Runner 应用日志。
  • 任务残留：工作区、临时目录、缓存、构建产物，以及 Keychain、证书文件、令牌等是否仍可访问。看工作流清理结果和主机侧记录，不能只看任务成功或失败。
  • 访问边界：哪些仓库、工作流和事件可以把 Job 派到这台主机。核对 Runner 组策略与工作流中的 runs-on，不要只检查 Runner 标签。

若你只是把同一仓库可信主分支的构建排到常驻机上，常驻方案维护直接、环境可复用；代价是工作流必须持续控制代码来源和权限。若代码来源无法保证，复用同一台主机就会把前序任务残留带入后续 Job。

02

按代码来源决定哪些任务能进入主机

同仓库的 Pull Request 也不能简单等同于可信代码。团队成员提交的分支与外部贡献者的分支，信任基础不同；更关键的是，工作流事件可能让代码在 macOS 主机上执行。GitHub 文档指出，来自 Fork 的 pull_request 工作流默认采用只读 GITHUB_TOKEN，且不会向 Runner 提供其他 Secrets；但这并不意味着自托管主机因此成为隔离环境。触发工作流的事件说明

先按事件分流：

  • 可信主分支的构建可以进入常驻 Runner，但只开放给指定仓库和工作流。
  • 可信团队成员的 PR，仍需检查其代码是否会执行脚本、构建插件或依赖安装任务，并核实对应 Job 能拿到什么令牌。
  • 外部 Fork 的 PR，不要派到带有签名凭据或其他敏感状态的常驻 Mac。采用托管执行环境、单任务后重建的隔离环境，或不运行这类工作流。
  • 不要为了给 PR 添加标签或评论，顺手在 pull_request_target 工作流里检出并执行 PR 代码。该事件具有更高信任权限；官方安全说明警告，运行不受信任代码可能引入凭据、缓存或写权限风险。安全使用 pull_request_target 的说明

仓库策略与工作流配置要一起查。组织 Runner 组可限制哪些仓库访问 Runner；部分设置还可以限制哪些工作流能够使用该组。Runner 组访问管理文档 即使标签写成 trusted，也不要把标签本身当成权限控制。去仓库设置里确认访问策略，再检查工作流触发器和 Job 的 Runner 选择。

03

按任务与凭据敏感度比较生命周期

方案 适合的任务 优点 主要风险与维护责任
受控常驻 Mac 仅限受信任仓库的日常构建；权限范围清楚 环境可复用，少做重复准备 任务状态可能残留；你需维护系统、Runner、清理流程与访问策略
临时或单任务 Runner 代码来源不稳定、任务间需要降低状态复用 Runner 单次接收 Job，有利于限制前序任务状态暴露 主机重建或销毁需另行实现；日志不会自动长期留存
托管执行环境 外部 PR 或不应接触自托管主机的工作流 不把不受信任代码直接送进你的常驻 Mac 构建环境与自定义工具链的准备方式需按工作流核验

表中的“单任务”描述的是 Runner 接收任务的行为，不是对物理主机、虚拟机或租用 Mac 自动重置的保证。GitHub 建议自动扩缩容采用临时 Runner，而不是持久 Runner；临时 Runner 完成一个 Job 后会从 GitHub 注销，但底层环境的清理仍需你配置。临时 Runner 与自动扩缩容文档

⚠️ 清理工作区能减少文件残留，却无法证明执行过不受信任代码的主机没有遭到持久影响。若你不能重建或验证主机环境，就不要把清理脚本当成隔离边界。

04

把签名发布从普通构建中拆出来

普通构建需要 Xcode 和项目依赖；签名发布还可能接触证书私钥、Provisioning Profile、Keychain 内容与上传凭据。把两种任务放进同一个可被普通 PR 触发的 Job，等于扩大了代码可接触的权限面。签名私钥不宜长期留在会运行不同来源代码的常驻 Runner 上。

你可以这样划分：

  • 普通构建 Job 不提供发布证书和上传凭据，GITHUB_TOKEN 也只授予完成该 Job 所需的最低权限。GitHub 支持在工作流或 Job 级别设置 permissions，并建议限制令牌权限。工作流权限语法说明
  • 签名、归档和上传另设发布 Job，只允许可信分支、受保护环境或经审核的工作流触发。
  • 只有发布 Runner 才能读取发布所需的凭据；Runner 组的仓库和工作流访问范围也要收紧。不要只靠“Secrets 放在环境里”就认为执行主机已隔离。
  • 任务结束后，核实证书与临时文件处理结果；需要时撤销或轮换凭据。保留脱敏配置、工作流运行记录和授权记录，便于复盘谁触发了发布。

如果发布任务仍需要常驻 Mac，至少限制哪些仓库和工作流能派任务过去，并避免让外部代码进入同一执行环境。Runner 组访问控制可以缩小可使用 Runner 的仓库和工作流范围，但它不替代主机隔离。Runner 组概念与访问边界

05

用可复核记录验收与恢复

选型不要停在配置文件。拿你自己的项目做一次代表性构建，再核对执行前后状态。下面这组步骤适用于决定常驻机能否承载可信构建，也适用于验证临时执行环境的交付边界：

  • 列出触发器：逐项检查 push、pull_request、pull_request_target、手动发布等事件，标记代码来自可信分支、团队成员还是外部 Fork。
  • 查 Runner 可达范围：核对 Runner 组允许的仓库与工作流，并确认普通构建和签名发布使用的 Runner 标签或组没有混用。
  • 查 Job 权限：检查 permissions、GITHUB_TOKEN、Secrets、证书与 Keychain 的暴露范围。尤其确认普通构建 Job 不会拿到发布凭据。
  • 跑代表性构建：记录所用工作流、触发来源、构建结果和 Runner 日志位置。不要把一次成功构建解读为安全验证。
  • 验证任务后处理：检查工作区、临时目录、缓存和凭据文件处理记录；如果方案承诺重建主机，则核对重建或销毁记录，而非只看清理步骤返回成功。
  • 演练失败恢复：检查 Runner 离线、任务中断或重建失败时，是否能停止继续派发任务、重新注册 Runner，并找到相应日志。

临时 Runner 的日志需要外部留存，不能假定实例销毁后诊断材料还在。GitHub 提供 Runner 应用日志用于排障，并建议将临时 Runner 日志转发到外部存储。Runner 监控与排障文档 核验时保存脱敏日志、任务结果、清理记录和凭据授权记录；不要把证书或令牌直接写入日志。

对照注册信息也有意义：GitHub 文档说明，未连接超过 14 天的常规 Runner 会自动移除；临时 Runner 的对应期限为 1 天。这只是注册记录的清理规则，不代表机器上的文件或凭据被安全擦除。移除自托管 Runner 的说明

06

常驻还是临时：按风险做决定

  • 只跑受信任私有仓库代码，且访问范围可限、清理可核验：选受控常驻 Mac。记录 Runner 日志、工作区状态和凭据处理，不让未经审核的任务进入。
  • 需要执行外部 PR 或其他不受信任代码：优先使用托管执行环境，或每项任务后销毁并重建的隔离环境。确认 Runner 只是单任务注册，不能代替检查底层主机生命周期。
  • Job 需要签名或发布凭据：与普通构建拆开，收紧触发条件、Runner 组及令牌权限。若你无法确认凭据只对发布 Job 可见，就不要把它留在共享常驻机上。
  • 无法证明清理有效，也无法重置主机：不要让该主机处理不受信任代码或高权限凭据。改用隔离环境，或不运行这类工作流。
07

常见问题

GitHub Actions 自托管 macOS Runner 能重复运行多个 Job 吗？

能。常驻 Runner 可在任务完成后继续在线，等待后续符合条件的 Job。复用主机意味着工作区、缓存和其他系统状态可能持续存在；你应分别检查 Runner 在线记录和任务后清理证据，不能因为下一个 Job 成功就认定主机干净。

外部 Pull Request 可以进入自托管 Mac Runner 吗？

技术上可能，但不应仅凭 Fork 工作流的令牌为只读、Secrets 默认不可用，就判断主机安全。PR 代码本身会在执行环境中运行。若主机保留敏感文件、凭据或其他任务状态，应把外部 PR 移到托管或可重建的隔离环境，而不是派给常驻签名机。

Job 结束后，工作区和凭据要怎么处理？

核对工作区、临时目录、缓存、构建产物、Keychain 会话和凭据文件，并保留脱敏日志与处理结果。对需要更强边界的任务，重建或销毁执行环境，并确认有重建记录。删除文件是清理措施，不是证明主机未受影响的安全证明。

iOS 签名密钥应该放在常驻 Runner 吗？

只有当常驻 Runner 的任务来源、访问范围和凭据授权都受控时，才考虑让发布 Job 临时使用签名凭据；不要让日常构建或 PR Job 共用这类权限。更稳妥的做法是拆分发布工作流、限制触发者与 Runner 访问，并验证凭据处理和授权记录。

如果你目前依赖办公室里的 Mac，主机离线、系统维护和本机状态都需要你自己管理；如果改用远程 Mac，仍需自行设计 Runner 的隔离、清理与凭据边界，租赁本身不会替你完成这些控制。开始验收前，可先查看 VpsMesh 远程 Mac 服务与接入概览，再按自己的工作流核对接入方式、可用配置和凭据管理要求。若你确实需要独立的 macOS 构建环境，也可查看 远程 Mac 环境与订购说明；不需要持续运行、或要求物理接口的任务，则应先评估本地 Mac 是否更合适。