[Bug]: leftover files cause hash collisions on APFS which prevents the OS from booting in a reasonable time

Minimal, reproducible example

import puppeteer from 'puppeteer';


//for (let i = 0; i < 10 ; i++) {
const args =  {headless: true, args: ["--disable-dev-shm-usage"]}
const browser = await puppeteer.launch(args);
const page = await browser.newPage();

// Set test content.
await page.setContent(`<div>test</div>`);
throw new Error("crash");

Background

My MacBook would no longer restart. The progress bar froze after login at about 10%. After some investigation, I found that in one directory, $TMPDIR (which is /var/folders/something/something/T), ls or find hangs forever. After further investigation, I found the following in the system log:

iterate_dirents_case_or_norm_insensitive:457: disk3s1 dirent hash chain iteration, dir_id 31714, hash 0x1c41b, count 400

This seems to be a hash collision on APFS. I moved the directory out of the way using the recovery system (ls did not work there either) and was able to boot again. Deleting the directory with rm -rf took about 2 hours just to start.

To my surprise, most of the folders there were named: com.google.chrome.for.testing.XXXXX and puppeteer_dev_chrome_profile-XXXX. These folder paths seem to trigger a hash collision on APFS quite easily. The problem was that in my Puppeteer code, browser.close() was not working as expected. When browser.close() is called, the files are removed.

Expectation

Puppeteer should name tempfiles so that it doesn't trigger an hash collision on APFS and should install an exit handler to remove temporary files even when browser.close() is NOT called.

Reality

Temporary files with are left over with a high chance for hash collisions on apfs.

Puppeteer configuration file (if used)

None

Puppeteer version

25.1.0

Node version

v26.3.0

Package manager

yarn

Package manager version

1.22.22

Operating system

macOS