check-package.mjs rejects valid npm tarballs when Windows tar emits CRLF

[ShawnSiao]

Summary

scripts/check-package.mjs rejects a valid npm tarball on Windows when the system tar command emits CRLF line endings for tar -tvzf.

The validation uses a multiline regular expression directly on the complete listing. In JavaScript, both CR and LF are line terminators for multiline anchors, so ^ can match between the \r and \n. The following \n is then tested as if it were the first character of a new line and triggers the non-regular-entry error.

Affected version and environment

• Released package: @openai/codex-security@0.1.1
• Confirmed still present on current main at f22d4a36f26d16287bcdfd707b369116e02a08c3
• Microsoft Windows NT 10.0.19045.0
• PowerShell 7.6.3
• Node.js 24.18.0
• pnpm 11.17.0
• bsdtar 3.5.2 / libarchive 3.5.2

Steps to reproduce

From the repository root:

cd sdk/typescript
corepack pnpm install --frozen-lockfile
corepack pnpm run build
corepack pnpm pack --pack-destination ../../dist
node scripts/check-package.mjs ../../dist/openai-codex-security-0.1.1.tgz

Observed error:

Error: npm tarball contains a non-regular entry (symbolic or hard link, device, or pipe).
    at scripts/check-package.mjs:185

I then captured the exact tar --ignore-zeros -tvzf output and checked every non-empty line. The generated archive contained 178 entries, and every listing line began with - or d; there were no links, devices, or pipes.

The package installation smoke test also passed:

Validated installed @openai/codex-security@0.1.1: public import, CLI, and 94 bundled plugin files.

A minimal diagnostic using the same listing demonstrated the false match:

/^[^d-]/mu.exec(listing) matches the LF in the first CRLF sequence.

Expected behavior

A valid npm tarball containing only regular files and allowed directories should pass check-package.mjs regardless of whether the local tar command emits LF or CRLF.

Actual behavior

The validator reports a non-regular tar entry before the later code normalizes the same listing with split(/\r?\n/u).

Impact

Windows contributors using a CRLF-emitting tar implementation cannot run the repository's package-boundary validation locally, even though the generated package is valid and installable.

Relevant code

• Current check:

  codex-security/sdk/typescript/scripts/check-package.mjs

  Lines 183 to 190 in f22d4a3

  	const listing = tar(["-tvzf", archive], "utf8");
  	if (/^[^d-]/mu.test(listing)) {
  	throw new Error(
  	"npm tarball contains a non-regular entry (symbolic or hard link, device, or pipe).",
  	);
  	}
  	const listingLines = listing.split(/\r?\n/u).filter(Boolean);
  	if (

• The code immediately below already creates normalized listingLines:

  codex-security/sdk/typescript/scripts/check-package.mjs

  Lines 188 to 198 in f22d4a3

  	}
  	const listingLines = listing.split(/\r?\n/u).filter(Boolean);
  	if (
  	listingLines.length !== entries.length ||
  	listingLines.some(
  	(line, index) => line.startsWith("d") !== entries[index].endsWith("/"),
  	)
  	) {
  	throw new Error("npm tarball contains an invalid tar entry.");
  	}
  	const launcherPermissions =

PR #3 introduced the package-boundary checker and validated a Windows CI configuration, but its patch and review discussion do not cover a tar implementation that emits CRLF for verbose listings.

Suggested direction

Normalize the listing before checking entry types and reuse the normalized lines for both validations. For example:

const listingLines = listing.split(/\r?\n/u).filter(Boolean);
if (
  listingLines.some(
    (line) => !line.startsWith("d") && !line.startsWith("-"),
  )
) {
  throw new Error(
    "npm tarball contains a non-regular entry (symbolic or hard link, device, or pipe).",
  );
}

A focused regression test can pass a CRLF-formatted verbose listing with only regular files and assert that it is accepted.

[zhuyuy]

I independently reproduced this on Windows NT 10.0.26200.0, PowerShell 7.6.3, code page 936, Node.js 22.22.1, and the project-declared pnpm 11.9.0, against f22d4a36f26d16287bcdfd707b369116e02a08c3.

The real build and pack completed, but the baseline package check reported a non-regular entry. The same archive contained 179 verbose-listing entries, all starting with d or -; the multiline regex matched the LF inside the first CRLF sequence.

I tested a minimal implementation reference that creates listingLines first and performs the entry-type check on those normalized lines:

zhuyuy@6c1cc7f

Validation with Node.js 24.15.0 and pnpm 11.9.0 passed type checking, the full formatting check, build, and pack. The fixed checker then reported:

Validated ...openai-codex-security-0.1.1.tgz: 179 entries.

For this focused validation I passed plugin-files.json explicitly so the unrelated install smoke was not rerun; I am not claiming that smoke as part of this result. Sharing the fork commit as an implementation reference because external PRs cannot be imported into the canonical source.