openai/codex · error · Error

Unsupported platform: ${process.platform} (${process.arch})

Error message

Unsupported platform: ${process.platform} (${process.arch})

What it means

The npm launcher maps Node's process.platform and process.arch to a Rust target triple to locate the vendored native binary under vendor/<triple>/codex-responses-api-proxy. Only linux/android, darwin, and win32 on x64 or arm64 are mapped; on any other combination determineTargetTriple returns null and the launcher throws before spawning the binary.

Source

Thrown at codex-rs/responses-api-proxy/npm/bin/codex-responses-api-proxy.js:46

      }
      break;
    case "win32":
      if (arch === "x64") {
        return "x86_64-pc-windows-msvc";
      }
      if (arch === "arm64") {
        return "aarch64-pc-windows-msvc";
      }
      break;
    default:
      break;
  }
  return null;
}

const targetTriple = determineTargetTriple(process.platform, process.arch);
if (!targetTriple) {
  throw new Error(
    `Unsupported platform: ${process.platform} (${process.arch})`,
  );
}

const vendorRoot = path.join(__dirname, "..", "vendor");
const archRoot = path.join(vendorRoot, targetTriple);
const binaryBaseName = "codex-responses-api-proxy";
const binaryPath = path.join(
  archRoot,
  binaryBaseName,
  process.platform === "win32" ? `${binaryBaseName}.exe` : binaryBaseName,
);

const child = spawn(binaryPath, process.argv.slice(2), {
  stdio: "inherit",
});

child.on("error", (err) => {

View on GitHub (pinned to 339751715c)

Solutions

Run under 64-bit Node (x64 or arm64) on Linux, macOS, or Windows - these cover every vendored triple
If Node is 32-bit, reinstall a 64-bit Node distribution
Build from source with cargo build -p codex-responses-api-proxy and invoke the binary directly, bypassing the launcher
Add os/cpu constraints to package.json or request a vendored build for the missing triple

Example fix

// package.json - stop installs on unsupported hosts
"cpu": ["x64", "arm64"],
"os": ["linux", "darwin", "win32"]

Defensive patterns

Strategy: validation

Validate before calling

const SUPPORTED = new Set(['linux-x64','linux-arm64','android-x64','android-arm64','darwin-x64','darwin-arm64','win32-x64','win32-arm64']);
const key = `${process.platform}-${process.arch}`;
if (!SUPPORTED.has(key)) {
  console.error(`no vendored codex-responses-api-proxy binary for ${key}`);
  process.exit(1);
}

Type guard

function isSupportedTarget(platform = process.platform, arch = process.arch) {
  const osOk = ['linux', 'android', 'darwin', 'win32'].includes(platform);
  const archOk = ['x64', 'arm64'].includes(arch);
  return osOk && archOk;
}

Try / catch

try {
  await import('codex-responses-api-proxy/npm/bin/codex-responses-api-proxy.js');
} catch (e) {
  if (/^Unsupported platform/.test(e.message)) {
    console.error('fall back to a from-source or PATH-installed binary');
    process.exit(1);
  }
  throw e;
}

Prevention

Declare cpu and os fields in package.json so npm skips unsupported hosts
Check platform/arch in install scripts before using the package
Document a from-source build path for exotic platforms

When it happens

Trigger: Running the package on Node where (platform, arch) is outside the matrix: linux ia32 (32-bit x86), linux arm (32-bit ARM such as armv7l), freebsd/openbsd/sunos/aix, or any arch string other than x64/arm64.

Common situations: 32-bit Node installations; BSD or Solaris hosts; Raspberry Pi 32-bit userspace; installing the package on all machines via a lockfile without os/cpu filters, so the launcher lands where no binary is vendored.

Related errors

AI-assisted analysis of openai/codex@339751715c (2026-08-25). Data as JSON: /api/errors/6ae7ebc3b497d7bf. Report an issue: GitHub.