fix(runtime): reclaim credential-home locks whose owner names no process

[rohanpoudel2]

Refs #228

Problem

recoverStaleCredentialHomeLock consulted process.kill(pid, 0) for any owner.json whose pid was a number:

if (isRecord(owner) && typeof owner["pid"] === "number") {
  try {
    process.kill(owner["pid"], 0);
    return false;

POSIX gives two of those numbers special meanings — 0 signals the caller's own process group and -1 every process it may signal — so both always succeed and always report a live owner. A fractional or out-of-range value makes process.kill throw ERR_INVALID_ARG_TYPE, which is neither ESRCH nor EPERM and was rethrown raw out of a public API.

The age check sits in the else branch, so a lock naming any of these values was also exempt from it. acquireCodexSecurityCredentialHomeLock therefore waited on such a lock forever, at a 25 ms poll, with no message and no timeout — while every other stale path (missing or corrupt owner.json) has a 30 s escape hatch.

Measured against the public API, with a 1.5 s abort as the only way out:

dead pid, 1h old (control)                     ACQUIRED in 2ms
no owner.json, 1h old (control)                ACQUIRED in 1ms
pid 0 -> process group, 24h old                ABORT_ERR: hung 1500ms
pid -1 -> every process, 24h old               ABORT_ERR: hung 1502ms
pid 0.5 -> ERR_INVALID_ARG_TYPE                ERR_INVALID_ARG_TYPE: hung 1ms

Change

Consult process.kill only for a positive safe integer. Anything else is an owner that cannot be identified, and is now treated exactly like a missing one, so the existing 30 s age check reclaims the lock. After the change the same three cases acquire in 2 ms.

The EPERM handling is unchanged and still means "the process exists but we may not signal it".

Scope: what this deliberately does not fix

A genuinely reused pid is still indistinguishable from the original owner, so a lock left behind by a SIGKILLed scan is still never reclaimed. I left that out on purpose:

• The lock is held for the entire scan (acquired in #run before runtime initialization, released in the outer finally), and scans legitimately run well over an hour (Standard full-repository scan shows only generic heartbeat for 40+ minutes — expected behavior? #70, Detect and warn from HEAD drifting earlier #164). A plain absolute age ceiling would therefore let one scan steal a running scan's lock — strictly worse than the current behaviour.
• Doing it correctly needs a heartbeat — the holder refreshing the lock's mtime while it works, and recovery reclaiming a lock whose mtime has stopped advancing. That is a design decision about the locking protocol, not a drive-by fix.

#228 documents that part, including why it is close to guaranteed in the shipped container (Dockerfile puts the state dir under the /output bind mount, and compose.yaml sets init: true, so container pids restart from 1 each run and a leftover low pid collides). Happy to implement the heartbeat if you tell me which shape you want.

Verification

New test recovers credential-home locks whose owner names no process walks [0, -1, 0.5, 2 ** 53], ages the lock past the 30 s threshold, and bounds the acquisition with an AbortController so a regression fails the test in 5 s instead of hanging it.

Before: AbortError: The operation was aborted. — 0 pass / 1 fail in 5002 ms.
After: 1 pass / 0 fail in 54 ms.

Full suite: 718 pass / 5 skip / 0 fail (717 baseline plus the new test). pnpm run types and pnpm run format are clean.

[mldangelo-oai]

@codex review exact head 8f0bc4d

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8f0bc4d3a3

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Security review completed. No security issues were found in this pull request.

Reviewed commit: 8f0bc4d3a3

View security finding report

Only the user who started this review can view the report in Codex.

ℹ️ About Codex security reviews in GitHub

This is an experimental Codex feature. Security reviews are triggered when:

• You comment "@codex security review"
• A regular code review gets triggered (for example, "@codex review" or when a PR is opened), and you’re opted in so security review runs alongside code review

Once complete, Codex will leave suggestions, or a comment if no findings are found.