Install Codex on Linux too, from the ansible role

[ldayton]

The Brewfile has had Codex since it was added, but inside if OS.mac? — Homebrew publishes only a cask for it, and casks are macOS-only. Linux was left with a comment telling you to run npm yourself, which meant a freshly provisioned box did not have it.

So the role installs it, the way it already installs Claude Code: as the account, followed by a task that runs the thing and checks it answers. npm is the route OpenAI document beside the cask and it ships the same version, so this is the same tool arriving another way.

Which npm matters, and it is named rather than found. The argument for a global install being safe here is entirely the account's own Homebrew node — global means the prefix, and the account owns the prefix outright — so the install passes executable: {{ dev_user_brew_prefix }}/bin/npm, and a stat decides whether there is one to pass. A box whose prefix has no npm is left alone. Letting the PATH choose instead is what the executed-role job caught: it runs with dev_user_brewfile: false, the runner's own npm took the install, the package landed in a prefix somewhere else, and the check went looking in the Homebrew one and found nothing.

The check needs the PATH for a reason the install does not: what npm links into the prefix is a script whose shebang is /usr/bin/env node, so running it needs node found the same way. Claude Code's check escapes that only because its installer leaves a native binary behind — copying its shape is what produced env: 'node': No such file or directory on a box where the install had just succeeded.

dev_user_codex_version pins a release for the reason dev_user_claude_code_channel does; empty takes the latest. ansible_env became ansible_facts.env at all three sites while here, since the injection behind the old name goes away in ansible-core 2.24 and every run of this role warns about it.

Run against a Linux host — the Loom CI runner, brew prefix owned by the account — both ways: with the prefix, ok=4 and changed=0 on a second pass, codex-cli 0.149.0 answering; with the prefix pointed at a path that has no npm, both tasks skip and nothing fails. The executed-role job takes the second of those, so it proves the pair is harmless on a Brewfile-less box rather than proving the install; that half has been shown only on the host above.

https://claude.ai/code/session_01WtqyKhgRvif4j6BMzZMTkA

[ldayton]

Ran these two tasks on a Linux host (the Loom CI runner, brew prefix owned by the account) and the check task failed where the install succeeded:

TASK [Codex answers]
fatal: [localhost]: FAILED! => {"cmd": ["/home/linuxbrew/.linuxbrew/bin/codex", "--version"], "rc": 127,
  "stderr": "env: 'node': No such file or directory"}

What npm links into the prefix is a script with a /usr/bin/env node shebang, so running it needs node on the PATH the same way the install needs npm on it. The Claude Code check above gets away without one because its installer leaves a native binary. d3fa167 adds the environment: block to the check; with it the role is ok=3 changed=0 on a second run, and codex-cli 0.149.0 answers.

https://claude.ai/code/session_01RnyoBGq5XfivVqbEWMzrmE