What causes "Could not parse process identity for ${pid}" in stablyai/orca?

Pin LC_ALL=C for ps invocations

stablyai/orca · error · Error

Could not parse process identity for ${pid}

Error message

Could not parse process identity for ${pid}

What it means

processIdentity(pid) runs `ps -p <pid> -o pid=,pgid=,command=` and expects output matching ^(\d+)\s+(\d+)\s+(.+)$ (pid, pgid, command). If the output does not match, it throws. However, the outer catch (line 28) attempts signalProcess(pid, 0) — if that returns ESRCH (no such process), it returns null. So this error only propagates if the process IS alive but ps output is unparseable.

Source

Thrown at config/scripts/macos-computer-helper-owner-loss-processes.mjs:25

const processIdentityOperations = {
  executePs: execFileSync,
  signalProcess: process.kill.bind(process)
}

export function processIdentity(pid, operations = processIdentityOperations) {
  if (!Number.isInteger(pid) || pid <= 0) {
    return null
  }
  try {
    const output = operations
      .executePs('ps', ['-p', String(pid), '-o', 'pid=,pgid=,command='], {
        encoding: 'utf8'
      })
      .trim()
    const match = output.match(/^(\d+)\s+(\d+)\s+(.+)$/)
    if (!match) {
      throw new Error(`Could not parse process identity for ${pid}`)
    }
    return { pid: Number(match[1]), pgid: Number(match[2]), command: match[3] }
  } catch (error) {
    try {
      operations.signalProcess(pid, 0)
    } catch (lookupError) {
      if (lookupError?.code === 'ESRCH') {
        return null
      }
    }
    throw error
  }
}

function matchingDetachedProcesses(identities, expectedCommandFragments) {
  return identities.filter(
    (identity) =>
      identity.pgid === identity.pid &&

View on GitHub (pinned to 1136503c6a)

Solutions

Pin LC_ALL=C for ps invocations
If the process is alive but ps fails, fall back to /proc-style inspection or proc_pidinfo via native bindings
Log the raw ps output to diagnose the format mismatch

Example fix

// before: ps may produce locale-dependent output for live process
const output = operations.executePs('ps', ['-p', String(pid), '-o', 'pid=,pgid=,command='], { encoding: 'utf8' })

// after: pin locale
const output = operations.executePs('ps', ['-p', String(pid), '-o', 'pid=,pgid=,command='], {
  encoding: 'utf8',
  env: { ...process.env, LC_ALL: 'C' }
})

Defensive patterns

Strategy: try-catch

Validate before calling

// Pin locale and check liveness before identity lookup
process.env.LC_ALL = 'C'
function safeProcessIdentity(pid) {
  if (!Number.isInteger(pid) || pid <= 0) return null
  if (!isProcessAlive(pid)) return null
  return processIdentity(pid)
}

Try / catch

// The function already has a built-in catch that returns null on ESRCH.
// Wrap the caller to handle the rare live-but-unparseable case:
try {
  return processIdentity(pid)
} catch (error) {
  if (error.message.includes('Could not parse process identity')) {
    console.warn('Live process has unparseable ps output:', pid)
    return null
  }
  throw error
}

Prevention

Pin LC_ALL=C for all ps invocations to ensure consistent field formatting
Check process liveness before calling processIdentity to avoid races
The built-in ESRCH catch already handles dead processes — this error only fires for live processes with malformed ps output

When it happens

Trigger: Process is alive (signal 0 succeeds) but `ps -p <pid> -o pid=,pgid=,command=` output does not match the three-field regex. Extremely rare: would require a non-standard ps, locale corruption, or kernel-thread PID with blank fields.

Common situations: Non-C locale altering ps field formatting; macOS ps version producing unexpected whitespace for special processes; the PID points to a kernel task with no command string.

Related errors

AI-assisted analysis of stablyai/orca@1136503c6a (2026-08-12). Data as JSON: /api/errors/2f6ac4a8a081f19b. Report an issue: GitHub.