Codex 跑完任务后留下进程怎么办？这是我的开源方案

在使用 Codex 做开发时，我们经常会让它运行各种命令：测试、构建、预览服务、浏览器自动化、DevTools MCP、Playwright、Vite、pytest、cargo、dotnet、Jupyter、Storybook 等。

这些命令有些是一次性的，跑完就应该退出；有些是长驻的，比如 dev、watch、serve；还有一些会拉起包装进程、子进程、浏览器调试进程或 MCP 辅助进程。时间一长，临时进程就可能堆起来。

问题是，清理这件事不能粗暴处理。

因为你不能简单地说：“看到 Node、Python、Chrome、cargo、pytest 就杀掉。”这些进程可能属于当前任务，也可能属于另一个项目；可能是刚刚结束的残留，也可能是用户还在用的开发服务；可能是 Codex 自动化拉起来的，也可能是普通浏览器或交互式 shell。

这就是我做 Codex Cleaning Temporary Processes 的原因。

项目地址：https://github.com/qiufengawa/codex-cleaning-temporary-processes

它是什么？

Codex Cleaning Temporary Processes 是一个公开、跨平台的 Codex skill，用来在开发过程中安全地重新评估和清理临时进程。

它的目标不是“尽可能多杀进程”，而是给 Codex 提供一套可复用的临时进程卫生纪律：

• 在合适的检查点后重新评估是否需要清理
• 先检查，再决定是否清理
• 只清理证据充分、已经没有复用价值的临时进程
• 保护当前 Codex shell、普通交互 shell、普通浏览器和仍可能复用的开发服务
• 保持多项目、多工作区、多对话之间的安全边界

简单说，它不是一个激进的进程终结器，而是一套面向 Codex 的“安全收尾规则”。

为什么需要它？

在真实开发任务里，Codex 可能会连续执行很多步骤：

• npm test
• vite build
• vitest
• cargo test
• pytest
• dotnet build
• tauri build
• 浏览器自动化
• DevTools MCP 检查
• 子代理并行任务

这些步骤结束后，有时会留下包装器、watchdog、测试 runner、remote-debug 浏览器链路或其他辅助进程。如果一直不处理，机器会越来越乱；但如果清理过度，又可能误杀用户正在使用的服务。

所以这个项目选择了一个更稳妥的思路：按检查点重新评估，而不是等整个任务结束才想起来清理。

纯 Skill 形态，而不是后台插件

这个项目有一个很重要的设计边界：它是一个 纯 skill 包，不是宿主级插件，也不是常驻后台进程。

这意味着：

• 它不会向 Codex 宿主注入固定 hook
• 它不会创建定时器或后台守护进程
• 它不能保证百分之百自动触发
• 它依赖 Codex 的最佳努力隐式调用
• 如果环境没有自动调用，可以显式要求 Codex 使用 $codex-cleaning-temporary-processes

这个边界看似保守，但它很重要。因为临时进程清理本身就是高风险动作，越是靠近系统进程和开发环境，越需要明确地说清楚“我能做什么”和“我不能保证什么”。

核心理念：inspect first

这个 skill 的第一原则是：

先 inspect，再 cleanup。

也就是说，当一个触发型检查点结束后，Codex 应该先运行 inspect，查看当前有哪些临时进程、它们属于什么类别、是否有足够证据判断它们可以被清理。

只有当 inspect 明确报告存在 killable roots 时，才进入下一步 checkpoint-cleanup。

这能避免很多危险情况，例如：

• 误杀当前 Codex shell
• 误杀普通浏览器
• 误杀用户手动开的交互式 shell
• 误杀另一个项目里的 dev server
• 误杀另一个 Codex 对话留下的自动化进程
• 误杀仍然有复用价值的 watch / serve / preview 服务

三种清理模式

项目提供三种主要模式：

1. inspect

只检查和分类，不杀进程。

适合绝大多数不确定场景，也是所有清理动作之前应该先执行的步骤。

2. checkpoint-cleanup

用于已完成检查点之后，清理高置信度、已经没有复用价值的临时进程。

它比 full cleanup 更保守，尤其会保护可能仍然需要复用的长驻服务。

3. cleanup

用于最终清扫，适合剩余临时进程树已经明确无用的场景。

这个模式应该谨慎使用，不适合作为默认动作。

什么时候应该重新评估清理？

这个项目把触发节奏分成三类。

must reconsider now

这些场景结束后，应该立刻重新评估：

• 一次性高风险命令结束，例如测试、构建、打包、发布、lint、compile
• 一次性高风险命令失败
• 浏览器自动化结束
• DevTools MCP 或 remote-debug 工作结束
• 子代理任务完成
• 同一工作区的一批一次性命令结束
• 用户明确要求最终清扫

注意：这里的“must reconsider”不是“必须杀进程”，而是“必须重新评估”。

should reconsider soon

这些场景应该尽快重新评估：

• 长任务中进程残留开始堆积
• 某些辅助任务已经完成，但仍可能有部分进程会复用
• 多步骤任务中完成了一个明显阶段

这类场景通常更适合先 inspect。

do not reconsider from this checkpoint alone

这些场景不能单独作为强清理依据：

• 低风险读取、搜索、列目录命令
• 长驻 dev / watch / serve / preview 服务
• 单纯会话结束
• 没有可靠工作区信息的模糊场景

覆盖哪些工具链？

这个 skill 的覆盖范围比较广，不只面向 JavaScript 项目。

它会考虑这些主流生态中的临时进程：

• JavaScript / TypeScript：npm、pnpm、yarn、bun、vite、vitest、jest、webpack、rollup、next、nuxt、turbo
• Rust：cargo、rustc、tauri、trunk
• Python：python、uv、pip、pipenv、poetry、hatch、pytest、uvicorn、jupyter、streamlit
• JVM / .NET：java、mvn、gradle、kotlin、scala、dotnet
• 其他常见栈：go、ruby、bundle、rails、php、composer、artisan、elixir、mix、deno
• 函数式、脚本和科学计算生态：clj、lein、ghci、cabal、stack、ocaml、dune、Rscript、perl、lua、zig、julia
• 构建和报告工具：tox、nox、quarto、crystal、xcodebuild、bazel、buck2
• 浏览器自动化：chrome-devtools-mcp、Playwright 风格工具、无头浏览器、remote-debug 启动链

不过这里要强调：覆盖广不代表清理激进。

这个项目一直坚持：覆盖范围越广，越要保持保守的安全边界。

显式自动化为什么更严格？

浏览器自动化、DevTools MCP、remote-debug 这类进程风险更高。

因为它们可能看起来像普通浏览器，也可能属于其他 Codex 对话或其他项目。如果仅凭“工作区匹配”就清理，很容易误杀。

所以这个 skill 要求：

• 显式自动化必须有当前任务链路或当前线程确认归属
• 不能只靠工作区匹配授权清理
• -ConfirmCurrentThreadExplicitAutomation 只用于刚刚确实发生过同线程自动化后的第一次跟进 inspect
• 当前线程 ownership 只收窄显式自动化范围，不会放宽普通 runtime 的清理权限

这也是整个项目最关键的安全设计之一。

多项目隔离

现实中，开发者可能同时开着多个项目、多个工作区、多个 Codex 对话。

这个 skill 必须保证：

• A 项目的清理不会误伤 B 项目
• 一个 Codex 对话不会回收另一个对话的进程
• 普通浏览器和普通交互 shell 不会因为长得像自动化链路就被误杀
• 工作区匹配只是证据之一，不是最终授权

这使得它更适合真实开发环境，而不是只能在理想 demo 里使用。

如何安装？

把这个仓库安装到 Codex skills 目录：

CODEX_HOME/skills/codex-cleaning-temporary-processes

需要保持这些内容在一起：

• SKILL.md
• agents/openai.yaml
• scripts/
• docs/

如果你的环境支持隐式调用，Codex 会在合适场景尽力使用它。

如果没有触发，可以明确告诉 Codex：

使用 $codex-cleaning-temporary-processes 检查并清理当前任务留下的临时进程。

常用命令

Windows：

powershell -ExecutionPolicy Bypass -File "$env:CODEX_HOME\skills\codex-cleaning-temporary-processes\scripts\cleanup-temporary-processes.ps1" -Mode inspect -Workspace "C:\Projects\ExampleApp"

macOS / Linux 使用 PowerShell：

pwsh -NoProfile -File "$CODEX_HOME/skills/codex-cleaning-temporary-processes/scripts/cleanup-temporary-processes.ps1" -Mode inspect -Workspace "/Users/example/project"

macOS / Linux 使用 shell wrapper：

bash "$CODEX_HOME/skills/codex-cleaning-temporary-processes/scripts/cleanup-temporary-processes.sh" -Mode inspect -Workspace "/Users/example/project"

如果刚结束的检查点确实使用了同线程 DevTools MCP、浏览器自动化或远程调试，那么第一次后续检查可以加：

-ConfirmCurrentThreadExplicitAutomation

但这个参数必须和非空工作区一起使用，并且不能把它当成通用清理授权。

测试方式

项目使用 Pester 测试 PowerShell 脚本逻辑。

可以运行完整测试：

Invoke-Pester -Path .\scripts -PassThru

也可以分别运行：

Invoke-Pester -Path .\scripts\process-inventory.Tests.ps1 -PassThru
Invoke-Pester -Path .\scripts\process-classification.Tests.ps1 -PassThru
Invoke-Pester -Path .\scripts\cleanup-policy.Tests.ps1 -PassThru
Invoke-Pester -Path .\scripts\thread-ownership-ledger.Tests.ps1 -PassThru
Invoke-Pester -Path .\scripts\cleanup-temporary-processes.Tests.ps1 -PassThru
Invoke-Pester -Path .\scripts\skill-trigger-contract.Tests.ps1 -PassThru

当前版本状态

截至本文编写时，项目最新 tag 为 v0.8.1。

仓库主分支在 v0.8.1 之后还有文档增强提交，用来补充全局 prompt 强化方案。

总结

Codex Cleaning Temporary Processes 解决的不是“如何杀进程”这个表面问题，而是“Codex 在真实开发流程里，如何有纪律地处理临时进程残留”。

它的价值在于：

• 让清理动作发生在正确检查点
• 让 Codex 先检查再行动
• 保护多项目和多对话边界
• 防止显式自动化进程被误判
• 保留可复用服务和用户工作流
• 用纯 skill 形态保持安装轻量和边界诚实

如果你经常让 Codex 执行测试、构建、浏览器自动化或多步骤开发任务，这个项目可以作为一层实用的“临时进程卫生纪律”。

项目地址：

https://github.com/qiufengawa/codex-cleaning-temporary-processes

Release：

https://github.com/qiufengawa/codex-cleaning-temporary-processes/releases