Incomplete .lock directory permanently blocks bulk-scan recovery

Version

@openai/codex-security@0.1.3

Also reproducible on commit f89633aeee1e73dc6406edf76657b49a8b51a43b.

Platform

macOS 26.5.1

What happened

Bulk scan creates its lock in two operations:

1. Create <output>/.lock.
2. Write <output>/.lock/owner.json.

If the process exits between those operations, later runs see .lock and immediately try to read owner.json. Because the file does not exist, recovery fails with ENOENT.

A malformed or truncated owner.json similarly throws during JSON parsing instead of being treated as an incomplete stale lock.

Reproduction

Create a repository CSV that uses a full immutable commit SHA. Then create an incomplete lock before starting the bulk scan:

mkdir -p results/.lock

npx @openai/codex-security bulk-scan repositories.csv \
  --output-dir results

Observed result:

codex-security: ENOENT: no such file or directory, open '.../results/.lock/owner.json'

Removing results/.lock allows the command to continue.

Expected behavior

A lock without valid owner metadata should be treated as incomplete or stale and recovered safely.

Why this can happen

Lock acquisition creates the directory before writing its owner metadata. A process termination, machine restart, or write failure during that window leaves a lock that later runs cannot reclaim.

The existing recovery behavior handles a valid owner file containing a dead PID, but not missing or malformed owner metadata.

Possible fix

Handle missing, malformed, or invalid owner metadata as an incomplete lock and reclaim it using the existing stale-lock path.

A more robust design could use one exclusively created lock file, write and sync its metadata, and include an owner token to make cleanup safer.