Scan prep crashes with "stdout maxBuffer length exceeded" on large repositories (0.1.11+)

[mahangu]

Summary

Since 0.1.11, codex-security scan <dir> --diff <sha> exits with code 2 within a second or two on repositories with large tracked-file counts, before any scan work happens. The only diagnostic is:

[00:00] Preparing scan
stdout maxBuffer length exceeded

Reproduced against a large public monorepo whose tracked-file listing is just over 1MB (roughly 14,000 files). The failure is independent of diff size: committed diffs changing fewer than a dozen files fail identically. Expected behavior: prep completes and the scan proceeds, as it does on 0.1.10 against the same repository.

Cause

Commit ecc608e (PR #368, first released in 0.1.11) added a sparse-checkout guard to committed-diff scans that lists every tracked file:

const tracked = await gitOutput(repository, ["ls-files", "-t", "-z"], signal);

gitOutput() in dist/targets.js runs git through execFile without a maxBuffer option, so Node's default 1MB cap applies:

const { stdout } = await execFile(command.executable, ["-c", "core.fsmonitor=false", "-C", repository, ...args], {
    encoding: "utf8",
    signal,
    env: command.environment,
});

(Quoted from 0.1.14; 0.1.11's gitOutput differs slightly but equally omits maxBuffer.)

On a repository whose git ls-files -t -z output exceeds 1MB, Node kills the child and the scan dies. The code is unchanged on main as of 2026-08-19 (sdk/typescript/src/targets.ts).

Reproduction

1. Create a repository whose tracked-file listing exceeds 1MB, for example 30,000 files with 60-character paths, and commit twice so a committed diff exists.
2. npm i @openai/codex-security@0.1.14 (--ignore-scripts is fine)
3. mkdir -m 700 /tmp/out (the CLI refuses an output directory with group or other permission bits), then OPENAI_API_KEY=placeholder codex-security scan <repo> --diff <first-commit-sha> --auth api-key --output-dir /tmp/out --max-cost 1 --json
4. The CLI exits 2 with stdout maxBuffer length exceeded during "Preparing scan", before any API call. Repeat with @openai/codex-security@0.1.10: the prep phase completes.

Any real-world monorepo of that size reproduces it the same way.

Suggested fix

Pass an explicit maxBuffer in gitOutput() (dist/runtime.js already uses maxBuffer: Infinity on one of its own call sites), or stream the listing instead of buffering it. Related: #249 tracks a similar whole-output buffering pattern for git diff --binary content digests.

Downgrading to 0.1.10 is not a clean workaround: it predates the head-revision guard PR #368 added, and its scan --diff save path has its own failure (#299).

Environment

• @openai/codex-security 0.1.11 through 0.1.14 (0.1.10 and earlier unaffected by this specific failure)
• Node 22.x; reproduced on Linux x86_64 and macOS arm64