codex-version defaults to empty, so a pinned action still installs an unpinned CLI

Summary

codex-version has default: '', and the description is just "Version of @openai/codex to install." Nothing signals that leaving it unset means npm latest at the moment the job runs.

The consequence is that pinning the action — even to a full SHA, which is the practice this repo's own README and every hardening guide recommend — does not pin what actually executes. Two runs of a byte-identical workflow, on an identical commit, minutes apart, can run different Codex binaries. There is no lockfile and no record in the workflow of what ran.

This is the same class of problem as #43 (setup-node unpinned), which was fixed. The difference is that this dependency is not an implementation detail — it is the program.

Why this is worth more than a docs tweak

It doesn't just cost reproducibility; it injects a confounding variable into every incident, and I have a concrete case.

We spent real effort diagnosing the post-output hang in #150 / #169 and initially blamed the wrong component. @openai/codex@0.149.1 published 2026-08-24T00:32Z; our first hang was 22 hours later, after 186 clean runs. That is a clean-looking correlation and it was wrong — the actual suspect is the v1.12 wrapper rewrite, whose tag moved 4 days earlier.

The reason the wrong answer survived scrutiny is structural, not careless. Because the CLI floats, two independent version boundaries sit within days of each other, and a workload-sensitive failure means the earlier boundary can produce a run of green results before the first red one. In our history the two are perfectly confounded: no run of ours can distinguish them. Breaking the tie required other organizations' data (a hang on 0.147.0, and 145/145 on v1.11 vs 69/74 on v1.12 with model held fixed).

Had codex-version been recorded per run, that would have been a lookup instead of a multi-org correlation exercise. I'd expect the same confound to have muddied #150 and #169 for others.

Suggestions, roughly in order of value

1. Echo the resolved version. Whatever the input is, log the concrete version and print it in the step summary, and expose it as an output. This alone fixes the forensics and is backward-compatible. Right now, when a run hangs and is force-killed, the log is never uploaded (gh run view --log returns log not found), so there is no post-hoc way to learn what CLI ran.
2. Document the default explicitly — "if unset, installs the latest published version at run time; pin for reproducible builds" — and recommend pinning in the README next to the action-SHA advice.
3. Consider defaulting to a version pinned per action release. Each action release knows the CLI it was tested against; defaulting to that makes uses: pin the whole stack, which is what users pinning a SHA already believe they're getting. This is the breaking-ish option, hence last, but it is the one that matches the mental model.

Happy to send a PR for (1) and (2) if that's welcome.

Environment

ubuntu-latest, GitHub-hosted. Observed while investigating #169 across 287 runs of one workflow.

Start by locating the codex-version input and the current package-install and logging entry points, then read the README guidance on action-SHA pinning. Done means the resolved CLI version is logged, included in the step summary and exposed as an output, while the README documents the empty default and recommends pinning.