选择等待模式

等待模式决定 Runner 启动所选程序后何时结束。对于先启动实际游戏、随后自己退出的启动器，这有助于让 Steam 继续跟踪整个会话。

等待模式不会补上成就逻辑、启用 Overlay，也不能保证某个 Steam 显示时长结果。配置后仍需验证实际游戏及其退出行为。

先使用 Windows 默认模式

新建 Windows 配置时，建议保留 高级设置 中的 等待程序及其子进程（推荐），保存值为 job。

旧配置如果没有明确的 wait_mode，含义仍然是 root；加载旧配置不会自动改成新默认值。如果启动器一关闭，Steam 就不再显示游戏正在运行，应检查当前选项。

只改等待模式，不会修改目标程序、工作目录或参数行。相关字段请参考详细配置。

在 Windows 上，Runner 先以挂起状态创建目标进程，将其加入 Windows Job Object，再恢复执行。Runner 会等待直接启动的程序，并等待该 Job 变为空。

因此，启动器先退出、游戏仍继续运行时，Runner 可以保持存活。关键边界是实际被分配到这个 Job 的进程。不能仅因为出现了游戏窗口，就认为独立代理、早已运行的服务，或启动器的特殊进程安排也属于它。

受控 Windows 进程测试，以及已记录的一种 CHS 启动器先退场景已经通过。这些结果不能证明所有启动器都兼容。如果你的游戏表现不同，应先确认实际入口和进程生命周期，再修改模式。

记录的退出状态是直接启动器的状态，即使 Runner 后来继续等待 Job 内的其他进程也是如此。日志中的退出码 0，不代表所有后代游戏进程都以退出码 0 结束。

Runner 启动所选程序，并等待这个直接进程退出。

如果所选 EXE 就是在整个游玩过程中保持运行的游戏本体，或你明确只需要等待该程序，可以使用此模式。如果它只负责启动另一个进程然后结束，Runner 可能在游戏仍然打开时就退出。这是 root 的预期限制。

对于先退出、再由已知游戏进程继续运行的特定启动器，可以明确选择这一兼容方式。

在 进程名称 中填写实际进程名，例如 ExampleGame.exe。这里精确匹配进程名称，不是文件路径或窗口标题；请按照实际运行程序显示的名称和拼写填写。

当前实现顺序如下：

检查间隔约为 100 毫秒。发现目标后的等待上限为 24 小时。达到限制会报告错误，并不能证明游戏会话已经正常结束。

启动前存在的同名进程会按进程身份排除，但启动后出现的无关同名进程仍可能被计入。这种模式不能证明进程属于你的游戏。在观察到之前就已经出现并退出的进程，也可能被漏过。

由于发现阶段在直接启动器退出后才开始，把实际游戏 EXE 同时设为启动目标和等待名称，通常不符合此模式的用途：开始查找时它可能已经结束。直接启动普通游戏时，应优先选择 job 或 root。

返回的退出状态属于启动器，不是所有匹配进程的退出码报告。

目标启动成功后，Runner 就结束，不等待游戏。如果目的是让 Steam 的运行状态持续覆盖整个游玩会话，这通常不是适合的选项。

此模式下的成功启动结果，只表示进程已经创建，不代表游戏内容或正常退出已经验证。

process_group 是保留的类 Unix 实现。当前 Windows Runner 会拒绝它，WinUI 也会对 Windows 配置禁用此选项。

明确标为 Linux 或 SteamOS 的配置可以在 Windows 预览版中查看，但不能编辑。这个选项不会提供 Windows 进程组，也不能证明 Proton 或 Steam Deck 兼容。新的 Linux/SteamOS 扩展仍然暂缓。

保存配置，保留 Steam 原启动选项，并在同一个 Steam 游戏库条目中使用生成的命令。测试前关闭 Manager。

观察实际游戏是否打开、启动器是否先退出，以及正常结束游戏后 Steam 是否回到停止状态。如果 Steam 一直显示运行中，先识别残留进程，再决定如何结束；启动器可能保留了辅助程序。不要仅为了清除状态指示，就强行终止仍有未保存进度的游戏。

日志与常见症状请参考排错指南。准确实现见 Runner 等待逻辑与 Windows Job 实现。