背景程序沒關，Codex 越用越卡？我揪出 126 個殘留 node，用排程自動收尾

💡 核心結論速覽 (TL;DR)

• 問題：AI 代理（Codex、Claude Code、Cursor，甚至各種自架 agent）會幫你開 node、dev server、Playwright、MCP 等背景程序來完成任務，但任務結束後常常沒收尾——累積下來吃光記憶體、占住 port，電腦越跑越卡。
• 不限於 Codex：只要那個 AI agent 會在你電腦上「跑指令、開服務」就可能中。最近電腦變慢，先去工作管理員抓一排沒在用的 node 背景程序。
• 千萬別亂殺：不要「一鍵殺光所有 node」——系統服務、資料庫、VPN 會一起陣亡，PID 還可能被系統重用而誤殺別的程式。安全解＝登記式清理（只清登記過又過期的，殺前比對 PID＋名稱＋啟動時間）。
• 行動：把清理腳本掛成每 6 小時自動跑的排程（Windows 工作排程器／macOS launchd／Linux cron）。我自己一次就清掉 126 個殘留行程——文末有可直接複製給 AI 的提示詞。

那天我的電腦又卡了。不是開太多分頁那種卡，是連切個視窗都要等一下的那種卡。我打開工作管理員想抓兇手——結果一整排 node、node_repl 排到我滑不到底，全是我根本沒在用的背景程序，記憶體被吃掉一大半。我當下愣住：這些東西到底哪來的？

答案有點尷尬：是我自己叫 AI 代理開的。我請 Codex 幫我跑開發、預覽、測試，它每次都很乖地把 dev server、Node 工具、Playwright 開起來完成任務——但任務做完、視窗關掉、session 一斷，這些背景程序常常沒人收尾，就這樣留在系統裡，一次留一兩個、越積越多。

這篇想跟你聊的，就是這個 AI 時代很典型、卻很少有人講的缺口：AI 代理很會「開」，卻不負責「關」。而且先講清楚——這件事不是 Codex 的專利，只要你用的 AI agent 會在你電腦上跑指令、開服務，都可能中。我會帶你看這些殘留行程在偷吃你什麼、Codex／Claude Code／Cursor 誰比較會留，然後重點來了：為什麼你千萬別直接「把所有 node 殺光」，以及我最後怎麼用一個每 6 小時自動跑的「登記式清理排程」把它一勞永逸解決掉。文末有可以直接複製的提示詞。

為什麼用了 AI 代理之後，電腦背景程序越積越多、越跑越卡？

先講結論：因為 AI 代理把「啟動服務」當成任務的一部分，卻很少把「關掉服務」也當成任務的一部分。它幫你跑一次預覽，就開一個 dev server；幫你測一次畫面，就拉起一個 Playwright 瀏覽器；接一個工具，就多一個常駐的 MCP 子行程。任務完成那一刻它回報「好了」，但那一個個背景程序還留在背景活著。

單獨看一個沒什麼，問題出在累積。你今天請它做三件事、明天五件事，每次留一兩個沒收的背景程序，一週後工作管理員裡就是幾十個 node 排排站。它們不一定有視窗、你也看不到，卻持續吃記憶體、占 CPU、霸著 port 不放。

這些殘留的背景程序到底在偷吃什麼？我把它整理成三筆帳：

❶ 記憶體：一支閒置的 Node／Next.js dev server 常常就吃掉數百 MB，編譯起來可以衝到好幾 GB（Next.js 官方文件自己也說，開發伺服器會把每頁的 JS 預載進記憶體，初始 footprint 偏大）。十幾支堆起來，你的 16GB 記憶體很快見底，於是你開始懷疑是不是該花錢升級硬體了。

❷ Port：dev server 預設都搶 3000、5173 這些 port。殘留的那支沒死、你下次要開新的，就會跳出經典的 EADDRINUSE: address already in use :::3000——很多人以為是專案壞了，其實是上一個沒關的背景程序還握著那個 port。

❸ 你的注意力：電腦變慢、風扇狂轉、東西跑不動，你以為該換電腦了，結果只是被一堆沒人收的背景程序拖垮。這是最貴的一筆——你可能因此花冤枉錢。

還有一筆很容易被忽略的——磁碟。這些工具除了開行程，還會在硬碟上留下暫存檔、log、artifact，跟一堆 Chrome／Edge 自動化用完沒刪的臨時瀏覽器 profile，默默佔空間。我那次光是清掉這些舊暫存與廢棄 profile（大概 50 個目錄），就釋放了快 1GB。

如果你有讓 AI agent 跑自動化測試，殘留的 headless 瀏覽器更是重災區，我在 放著 AI agent 跑 Playwright，結果一堆沒關的瀏覽器在背景燒資源 那篇就吃過這個虧。如果你還搞不太清楚這些 agent 到底在你機器上做了什麼，可以先看 AI agent 到底是什麼、會在你電腦上跑哪些東西。

下一步：現在就按 Ctrl+Shift+Esc 打開工作管理員（Mac 用活動監視器），看看 node 行程有幾個、吃掉多少記憶體——這個數字會嚇到你，也是你要不要往下讀的判斷依據。

Codex、Claude Code、Cursor 誰最容易留下背景程序？

先給判斷：三家都會開背景程序，但「收不收尾」差很多——Codex 目前最容易留殘留，Claude Code 設計上會自動收、但仍有邊界案例，Cursor 則是反覆開關會默默累積。下面這張表，是我自己用下來再對照官方說法與社群回報整理的：

講白一點：Codex 的 GitHub issue 裡 到現在還掛著一條「父行程結束後子行程仍殘留」的問題，官方自己寫著「所有子行程與後代都應該在結束時被終止並回收」——也就是它知道該收、卻沒收乾淨。社群甚至回報過最誇張的一例：桌面版累積到一千多個殭屍行程、上千個 node、吃掉約 37GB 記憶體（後來官方有修）。我那次清掉 126 個，跟這比根本是小兒科。

Claude Code 就誠實一點——它的 官方文件 白紙黑字寫「背景任務會在 Claude Code 離開時自動清理」、輸出超過 5GB 會自動終止，你也能按 Ctrl+X Ctrl+K 手動停掉背景子代理。設計上有在收尾，這點要給它肯定。但別完全放心：Windows 上仍有人回報 /exit 後 child 行程沒被殺乾淨。它在本機與雲端的隔離差別，我在 Claude Code 雲端環境 vs 本機怎麼選、哪個比較省 講得更細。

至於 Cursor，社群論壇有人回報關掉軟體後 MCP server 行程不會跟著死、下次再開又生一個。會自己開瀏覽器、操作畫面的 agent（像 Claude 那種能直接操作電腦畫面的 Computer Use 能力）也是同理，背景留下的東西更雜。

🚧 最容易誤會的一點：看到一堆 node 不代表 AI 工具「壞掉了」。它們大多是任務當下正常開的背景程序，只是任務結束後沒被收掉。所以解法不是換工具、也不是把 node 全殺光，而是幫這些服務「設一個下班時間」。

但重點是——這問題不限於這三個。只要你用的 AI agent 會在你電腦上「跑指令、開服務」，不管是別家的編程 agent、各種 自架的開源 AI agent、還是串了一堆工具的 MCP 工具鏈，都可能留下背景程序。所以如果你用的是別的 AI 工具、最近也覺得電腦越來越卡，別只怪電腦老——先用上面教的方法去工作管理員抓一排 node 出來看。它不是某個產品的 bug，是整個「AI 代理只負責開、不負責關」的通病。

下一步：先別急著怪某個工具。打開工作管理員，把 node 行程依「記憶體」排序，記下最肥的那幾個的 PID（行程編號）——等下安全清理時用得到。

那我直接把所有 node 行程殺光，不就好了？

先擋一下：拜託千萬不要。「一鍵殺光所有 node」是最直覺、也最容易出事的做法。我懂那種「看了就煩、想全部清掉」的衝動，但你電腦上的 node 行程，遠不只 AI 代理開的那些。

很多你天天在用、卻不知道底層是 node 的東西，都會一起陪葬：VS Code 的一堆擴充套件、本機跑的資料庫或快取、某些桌面 App、開發工具的語言伺服器⋯⋯你「咻」一下全殺，輕則編輯器當掉，重則正在寫的東西沒存到就飛了。更別說有些 node 行程是系統服務、VPN、雲端同步開的，根本不該你動。

還有一個更隱晦、工程師才會踩到的雷：PID 會被系統重用。你以為記下某個行程的 PID 就能放心等一下去殺它，但行程一結束，作業系統就會把那個編號回收、發給下一個新開的行程。你拿著一個過期的 PID 去 kill，很可能殺到的是後來剛開、完全無辜的另一個程式。這不是理論——連 Google 的建置工具 Bazel 都 出過這個包，文件裡寫得很白：因為 PID 被重用，「對隨機的行程群組送出 SIGKILL……真的發生過好幾次，殺掉了一些建置和測試」。

所以「無腦殺 node」會同時踩兩個雷：誤殺該留的（系統服務、資料庫、你正在用的工具），以及 因為 PID 重用誤殺無辜的。這也是為什麼我後面那套做法，會堅持「殺之前一定要再比對一次身分」。

下一步：把「kill 所有 node」這個念頭從清單上劃掉。我們要的是精準收掉「AI 代理開的、已經沒用的」背景程序，而不是無差別掃射。

真正安全的解法：用「登記式清理」幫背景程序設下班時間

直接講做法：核心觀念只有一句——「只清你登記過、而且已經過期的服務」，絕不掃全系統亂殺。這叫登記式清理（registry-based cleanup），跟「殺光所有 node」剛好相反：它是白名單思維，不是亂槍打鳥。

運作邏輯拆成三步，其實很單純：

❶ 啟動就登記：每次 AI 代理（或你自己）開一個本機服務，就把它的關鍵資訊寫進一個登記檔——至少要有 PID、服務名稱、port、啟動時間、TTL（存活時間，例如「2 小時後算過期」）、啟動者、執行路徑。沒登記的，清理腳本一律不碰。

❷ 只清過期的：清理腳本只看登記檔，挑出「已經超過 TTL」的服務來處理。它完全不掃描整個系統、不主動找 node 殺，所以 Redis、SQL Server、SSH、VPN、Google 雲端硬碟、Steam，甚至你自己開的 Chrome 主視窗，這些「不是它開的」常駐服務，永遠不在射程內。

❸ 殺之前再比對一次：這步是整套的靈魂。腳本要殺某個 PID 前，會再確認「現在這個 PID 的行程名稱、執行路徑、啟動時間，跟當初登記的對不對得上」。對不上（代表 PID 已經被系統重用成別的程式）就跳過、不殺。這一步直接擋掉前面講的 PID 重用誤殺——微軟自己的 PowerShell 官方文件 也把「除了行程編號之外、連名稱一起確認」列為最佳做法。

📌 為什麼這套比「定時殺 node」安全：因為它把判斷依據從「這是不是 node」換成「這是不是我登記過、又過期、而且身分還對得上的服務」。三個條件同時成立才動手，誤殺機率趨近於零。

那它適合誰、不適合誰？我幫你分一下：

✅ 你很適合上這套，如果你：常用 Codex／Claude Code／Cursor 或任何會開服務的 AI agent、本機同時跑好幾個專案、電腦已經開始無故變慢，又不想每次手動去工作管理員一個個殺。

❌ 先別急著上，如果你：只是偶爾用 AI 問問題、不太跑本機服務，或你根本分不出哪些行程是自己開的——那你更該先做的，是「每次任務結束、請 AI 順手把它剛開的服務關掉」，先把源頭的習慣建立起來，再談自動化。

成本呢？這套不用花錢買任何工具，純粹是腳本加上系統內建的排程器，真正的成本是大約 15 分鐘的設定時間。如果你本機真的被背景程序搞到很痛，也可以反過來想：與其讓長任務一直在本機堆行程，不如 把任務按工作型態分流到不同工具或雲端，本機就清爽很多。

另外，殘留的不只行程，還有暫存。所以我那套清理除了收行程，也會順手清開發資料夾裡超過 24 小時沒動過的低風險暫存（像 __pycache__、.pytest_cache、舊的 chrome-profile／edge-profile）。但這條界線不能模糊：node_modules、.git、env／token／OAuth 檔案、原始碼、文章圖片跟正式產物，一律排除——寧可少清，也絕不誤刪你的東西。

下一步：先決定你的 TTL。我自己抓「2 小時」當預設——一個 dev server 開超過 2 小時還沒人理，多半就是忘了關的殘留。你可以照自己的工作節奏調整。

怎麼把清理掛成每 6 小時自動跑的排程？（Windows／Mac／Linux）

先給結論：把清理背景程序的腳本交給系統內建的排程器，每 6 小時自動跑一次，當作最後一道防線。記憶只能提醒、不能當機制——你一定會有忘記收尾、或 session 突然斷線的時候，排程就是來接住這些漏網之魚的。三大系統都有現成工具，不用裝額外軟體：

以 Windows 為例，用系統管理員開 PowerShell，一行指令就能建好：

schtasks /create /sc hourly /mo 6 /tn "CleanupDevServers" /tr "powershell.exe -File C:\scripts\cleanup.ps1"

/sc hourly /mo 6 就是「每 6 小時一次」，/tn 是任務名稱、/tr 是要跑的腳本。建好之後怎麼確認它真的會動？去工作排程器看那個任務的 「上次執行結果」（LastTaskResult）是不是 0——0（也就是 0x0）代表成功執行，這是 微軟官方文件 定義的。我自己就是手動觸發一次、看到結果 0，才確定排程是活的。

Mac 用 launchd，把 StartInterval 設成 21600（單位是秒，21600 秒＝6 小時，要注意電腦睡著時這個間隔會被跳過）；Linux 用 cron 寫 0 */6 * * *，或 systemd timer 設 OnCalendar=*-*-* 00/6:00:00。邏輯都一樣：固定間隔，跑那支「只清登記過、又過期」的腳本。

幫你省一個我走過的彎路：我一開始手賤把它設成每 30 分鐘跑一次，後來改回 6 小時。因為這支排程的定位是 「最後防線」，不是即時監控——它要接的是「session 突然斷線」「我忘了收尾」這種漏網之魚，不需要分分秒秒盯著。跑太勤只是徒增系統負擔、頻繁掃描資料夾，還可能打斷正在跑的短任務；6 小時剛好，一天內能清好幾輪殘留，又不會吵到你工作。我把這個排程取名 CodexLocalServiceCleanup，建好後在工作排程器看到狀態 Ready、間隔顯示 PT6H，就知道它上線了。

最關鍵的是——裝完一定要自測，別等真的出事才發現腳本寫錯、把不該殺的殺了。我會這樣驗：開一個無害的臨時背景行程 → 把它登記成「已過期」→ 手動跑一次清理腳本 → 確認 只有這個測試行程被關掉、別的都沒事。過了這關，才敢讓它自動跑。

下一步：先別急著設排程。先確定你（或你的 AI）已經有一支「只處理登記檔、會比對身分」的清理腳本，而且通過上面的自測——腳本對了，排程才有意義。

直接複製這段提示詞，讓 AI 幫你把清理排程建好

最實用的來了：你不用自己寫腳本，把下面這段整段複製、貼給你在用的 AI 代理，它就會幫你把整套登記式清理加排程建起來。我特意把「安全條款」都塞好了——不准暴力清理、要登記、殺前要驗身分、暫存只清超過 24 小時的低風險目錄、最後還要自測——所以它照著做，基本上不會誤傷你的系統。

完整版（建議用這個，安全條款最齊全）：

請幫我建立一個安全的「本機開發環境自動清理排程」。

目標：
避免 AI 工具、開發伺服器、測試工具或瀏覽器自動化留下背景行程與暫存檔，導致電腦越用越卡。

請遵守以下原則：

1. 不要暴力清理
   不要直接殺掉所有 node、python、chrome、edge、java、npm、pnpm、vite、next 等行程。

2. 使用登記式清理
   只有明確登記過的本地服務才可以被自動關閉。
   登記資訊至少包含：
   - PID
   - 服務名稱
   - port
   - 啟動時間
   - TTL / 過期時間
   - process name
   - process path
   - 啟動者

3. 清理前要驗證
   關閉行程前，請比對 PID、process name、process path、啟動時間。
   如果 PID 已被系統重用，不可以關閉。

4. 不要碰使用者常駐服務
   不要清理資料庫、VPN、SSH、雲端同步、瀏覽器主 session、系統服務、使用者自己開的應用程式。

5. 加入安全暫存清理
   可以清理開發工作區內超過 24 小時未更新的低風險暫存，例如：
   - __pycache__
   - .pytest_cache
   - .codex-tmp
   - chrome-profile*
   - edge-profile*
   - tmp-edge-*

   但必須排除：
   - .git
   - node_modules
   - env / token / secret / OAuth 檔案
   - 原始碼
   - 文章、圖片、報告、資料庫或正式產物

6. 建立低頻排程
   請每 6 小時執行一次清理即可。
   這是防止殘留的保險，不需要高頻監控。

7. 請依照我的系統選擇排程方式
   - Windows：Task Scheduler
   - macOS：launchd
   - Linux：systemd timer 或 cron

8. 請提供以下內容
   - 登記服務的方法
   - 清理腳本
   - dry-run 模式
   - log 檔位置
   - 安裝排程方法
   - 查詢排程狀態方法
   - 停用或移除排程方法

9. 建立後請自測
   請啟動一個無害的臨時背景行程，登記它，設成過期，執行清理，確認只有這個測試行程被關閉。

10. 最後請回報
   - 排程名稱
   - 執行頻率
   - 下一次執行時間
   - 測試結果
   - 清理範圍
   - 明確不會清理哪些東西

如果你只想快速講重點，這個懶人版也夠用：

請幫我建立一個安全的本機開發環境清理排程：只清理已登記且過期的本地服務，並清理超過 24 小時的低風險暫存；不要亂殺所有 node/python/chrome 行程；每 6 小時執行一次，附 dry-run、log、自測與移除方式。

提醒一下：建立排程通常要系統權限，所以貼之前最好在開頭補一句「請先檢查我的作業系統和權限，需要管理員權限就先告訴我原因再繼續」，讓它先說清楚再動手，比較安心。對了，清理排程救得了你的記憶體，可救不了你的 API 用量帳單；如果你還在猶豫要不要付費版 AI 來跑這些，可以參考 AI 免費版到底夠不夠用、那筆月費該不該付 跟 哪些 AI 訂閱真的值得續。

下一步：把完整版提示詞複製給你的 AI 代理，先讓它回報「作業系統＋目前權限＋它打算建立什麼」，你確認沒問題再讓它執行。

FAQ 常見問題

我用的不是 Codex，是別的 AI agent，也會有這個問題嗎？

很可能會。只要那個 AI 工具會在你電腦上「執行指令、啟動服務」——不管是別家的編程 agent、自動化工具，還是串了 MCP 的工具鏈——就有機會留下沒收尾的背景程序。判斷方法很簡單：最近電腦無故變慢，就打開工作管理員（Mac 用活動監視器）依記憶體排序，看看有沒有一排你沒在用的 node、python 或瀏覽器行程。有，就是同一類問題，後面那套登記式清理一樣適用。就算你不是工程師也別怕，可以先看 非工程師到底值不值得學這類 AI 編程工具 建立基本概念。

每 6 小時清一次，會不會把我正在用的服務也殺掉？

不會，前提是你照「登記式清理」做。腳本只動「你登記過、而且已經超過 TTL」的服務，沒登記的完全不碰；殺之前還會再比對 PID、行程名稱、啟動時間對不對得上。你正在用的服務只要 TTL 還沒到、或根本沒被登記，就不在清理範圍。會怕的話把 TTL 設長一點（例如 4 小時），再搭配安全自測，基本上不會誤殺。

登記式清理 vs 直接寫個排程定時 kill 全部 node，差在哪？

差在「會不會誤殺」。定時 kill 全部 node 看起來省事，但它分不出哪些是 AI 代理開的殘留、哪些是 VS Code、資料庫、VPN 在跑，一律殺掉就會出事；而且 PID 被系統重用時還會誤傷無辜行程。登記式清理是白名單：只處理登記過又過期的，殺前再驗一次身分，安全性差很多。省那幾分鐘設定的代價，可能是某天你正在寫的東西被殺掉、又沒存檔。

清掉這些背景程序，電腦真的會變快嗎？

會有感，但要看你原本積了多少。如果工作管理員裡躺著幾十支沒用的 node、吃掉好幾 GB 記憶體，清掉之後記憶體和 CPU 立刻鬆一大口氣、風扇也安靜下來。但如果你本來就只有一兩支，那影響有限——這套的價值在於「長期不再累積」，而不是一次性提速。它治的是慢性病，不是急救。

這跟「把任務丟到雲端跑」是不是同一件事？

不是，但可以互補。把長任務丟到雲端 VM 跑，是讓背景程序根本不在你本機產生（從源頭減量）；登記式清理則是處理「已經在本機跑、又沒收尾」的那些。兩個一起用最乾淨：能上雲端的長任務上雲端，留在本機的短任務靠排程收尾。雲端跟本機到底怎麼分，我在 Codex 雲端環境 vs 本機環境，兩個 agent 在我電腦上搶 port 的那場大戰 那篇有完整比較。

結論：AI 代理該負責的不只是「開」，還有「關」

回頭看那天工作管理員裡那一排 node，我其實有點哭笑不得——我一直以為 AI 代理幫我省了時間，結果它在背景默默把成本轉嫁到我的電腦上。只開不關，短期看起來很有效率，長期是用你的記憶體、你的 CPU、你的電費在買單。

所以這件事的解法，從來不是「我下次記得關」。記憶只能提醒、不能當機制。真正可靠的做法，是把本機服務當成「有生命週期的資源」來管：啟動要登記、完成要關閉、過期自動清理，再用一個每 6 小時跑一次的排程當最後防線。我那次清掉 126 個殘留行程、設好排程、跑完自測看到結果 0 的時候，電腦終於不再無緣無故卡了。

而且記得——這不是 Codex 的專利。任何會在你電腦上跑東西的 AI agent 都可能有同樣的缺口，發現電腦越來越卡，就去抓一下背景程序。AI 確實沒讓我更清閒（這點我在 為什麼用了 AI 之後，我反而更忙了 那篇碎念過），但至少現在我的電腦不會跟著一起累垮。覺得這篇有幫到你的話，可以訂閱我的部落格，我會不定期把這類踩坑筆記寄給你。

參考資料

• OpenAI Codex — Orphaned child processes persist after parent exits（issue #15379）
• Claude Code 官方文件 — 背景任務在離開時自動清理、5GB 上限與停止快捷鍵
• Microsoft Learn — schtasks /create（每 N 小時排程與 Last Result: 0）
• Microsoft Learn — Stop-Process（殺行程前連名稱一起確認的最佳做法）
• Bazel — PID 重用導致誤殺隨機行程的真實事故（issue #11910）
• Next.js 官方文件 — 開發伺服器的記憶體使用
• 關於作者夜羽凌