codex - 💡(How to fix) Fix install.sh fails to find package SHA-256 on Debian/Ubuntu mawk

What version of Codex is running?

Installer fetched from https://chatgpt.com/codex/install.sh on 2026-05-28. Latest release observed via GitHub API was rust-v0.134.0.

What platform is your computer?

Debian/Ubuntu systems where /usr/bin/awk resolves to mawk rather than gawk.

What steps can reproduce the bug?

Run the standalone installer on a Debian/Ubuntu environment that has the default mawk implementation for awk:

sh -c 'curl -fsSL https://chatgpt.com/codex/install.sh | sh'

Or isolate the failing parser from scripts/install/install.sh:

asset=codex-package-x86_64-unknown-linux-musl.tar.gz
printf '%s  %s\n' \
  0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef \
  "$asset" > /tmp/codex-package_SHA256SUMS

awk -v asset="$asset" '
  $2 == asset && $1 ~ /^[0-9a-fA-F]{64}$/ {
    print tolower($1)
    found = 1
    exit
  }
  END {
    if (!found) {
      exit 1
    }
  }
' /tmp/codex-package_SHA256SUMS

What is the expected behavior?

The installer should parse codex-package_SHA256SUMS and verify/install the downloaded archive on stock Debian/Ubuntu systems without requiring users to install gawk first.

What actually happens?

The installer exits while resolving the package archive digest:

Could not find SHA-256 digest for codex-package-x86_64-unknown-linux-musl.tar.gz in codex-package_SHA256SUMS.

Installing GNU awk works around the failure:

sudo apt install gawk

A user reported that workaround in #24035, but that issue is primarily about the daemon/updater invoking the standalone installer from a mixed install context. This issue is the narrower installer-portability problem.

Suspected root cause

package_archive_digest() currently uses an AWK interval expression:

$2 == asset && $1 ~ /^[0-9a-fA-F]{64}$/ {

Some mawk versions shipped as the default awk on Debian/Ubuntu do not support {64} interval regex syntax in the same way as gawk, so the digest line is not matched and the installer reports a missing SHA-256 even though the checksum file contains it.

The installer already uses shell pattern matching elsewhere for a 64-character SHA-256 string, for example:

sha256:????????????????????????????????????????????????????????????????)

A portable fix would avoid AWK interval regexes here, for example by checking length($1) == 64 plus a character-class match that does not use {64}, or by using POSIX shell pattern validation after extracting the first field.