Vitestのゾンビプロセス対策

Claude CodeやCodex CLIでvitestを実行させると、ゾンビプロセスとしてvitestのプロセスが残り、メモリを大量消費してしまうことがある。
devcontainerの中でyoloさせる身としてはこれが起こるとたいへん困る。

vitestを何も設定せずに実行するとwatchモードになるのが原因ではないかと考えた。
実際、以下のような記事もあった。

AI支援ツールがメモリを食い潰す？ Claude Codeが起こした「Vitest暴走事件」の顛末と再発防止策 - UPSIDER Techblog https://tech.up-sider.com/entry/20250707_card-division

某Slackコミュニティでも当該現象の解決方法として同様の解決方法が挙げられていた。

vitest runまたはvitest --runを実行する

vitest.config.tsを以下のように設定する

vitest.config.ts

export default defineConfig({
	test: {
		watch: false,
	},
});

しかし、これらのの方法でコマンドをワンショットにするだけでは効果がなく、この設定私の環境では問題が何度も起きた。

そもそもこの問題は、vitestがテストを並列実行するためにプロセスforkを使用していることが関連していると思われる

plaintext

node@1def37443e2d:/workspace$ ps aux | grep vitest
node       15248  114 10.4 14835164 3404920 ?    Rl   08:46   3:03 node (vitest 2)
node       15255  112 10.4 4339064 3389236 ?     Rl   08:46   2:59 node (vitest 4)
node       15262  110  9.9 14686244 3252056 ?    Rl   08:46   2:56 node (vitest 6)
node       15290  108 10.0 14708772 3272780 ?    Rl   08:46   2:52 node (vitest 9)
node       15309  109 10.3 4595184 3382668 ?     Rl   08:46   2:55 node (vitest 10)
node       15659  110  9.4 4035896 3084124 ?     Rl   08:46   2:56 node (vitest 13)

コーディングエージェント経由でvitestを実行するとなぜforkされたプロセスが残ってしまうのかの調査はできていない
しかし、プロセスが残るのが原因であれば、マルチスレッドによる並列実行に変更すれば問題は解消されるのではないかと考えた。

vitest.config.ts

export default defineConfig({
	test: {
		pool: 'threads',
	},
});

この方法で問題が解消された。

ただし、ドキュメント https://vitest.dev/config/#pool によると

Some libraries written in native languages, such as Prisma, bcrypt and canvas, have problems when running in multiple threads and run into segfaults.

とあるので、万能な解決策ではない。

threadsが使えないときにはforkのまま単一のプロセスを使うように設定するのが良いだろう。

Configuring Vitest | Vitest https://vitest.dev/config/
Command Line Interface | Guide | Vitest https://vitest.dev/guide/cli