codex_version can't be bumped: the weekly rule's confirmation isn't reachable from CI

[tend-agent]

codex/action.yaml pins codex_version: 0.131.0-alpha.22. The alpha line is now 0.148.0-alpha.5 and the stable line is 0.147.0 — seventeen minors of drift, and it has not moved since the pin was introduced.

The running-tend weekly rule is deliberately conservative here: "keep it on its prerelease line; bump only to a release confirmed to run under codex exec." The problem is that nothing in this repo can produce that confirmation. There is no harness: codex override in .config/tend.yaml, no codex step in ci.yaml, and no OpenAI credential reachable from a weekly run — so a live codex exec session is not something the weekly job can perform, and the bump condition can never be satisfied by the bot. The pin drifts by default rather than by decision.

What I can verify from CI, and did this week against 0.148.0-alpha.5, is that the CLI surface the action depends on is intact:

Surface probe against 0.148.0-alpha.5

$ npm install @openai/codex@0.148.0-alpha.5
$ codex --version
codex-cli 0.148.0-alpha.5

$ codex exec --help        # every flag the action passes is still accepted
  -m, --model <MODEL>
  -s, --sandbox <SANDBOX_MODE>
  -o, --output-last-message <FILE>
  -c, --config <key=value>

$ codex plugin marketplace add <repo root>
Added marketplace `tend` from /home/runner/work/tend/tend.

$ codex plugin add tend-ci-runner@tend
Added plugin `tend-ci-runner` from marketplace `tend`.
Installed plugin root: <path>

The Installed plugin root: line is the one the action parses with awk to set CLAUDE_PLUGIN_ROOT; it still has that exact prefix.

That covers the flags and the plugin-install parse, which is where a silent break would most likely land. It does not cover an actual agent session — model selection, model_reasoning_effort, sandbox behavior, or whether the final message reaches --output-last-message.

Two ways to close the gap, both cheap relative to letting the pin rot:

1. A codex smoke in ci.yaml, gated on an OPENAI_API_KEY secret in the tend environment, running one trivial codex exec against the pinned version. That makes the weekly bump self-verifying and is the version of this that doesn't need a person each time.
2. A harness: codex override on one low-stakes workflow (the pattern .config/tend.yaml already supports for trialling a harness per workflow), so the pin gets exercised by real runs and a bad bump surfaces on a workflow whose failure costs little.

Until one of those exists, the weekly run will keep reporting this drift and declining to act on it, which is the correct behavior under the current rule but not a good steady state.

[tend-agent]

Confirmed the diagnosis and opened #923 for the half that doesn't need a credential.

The load-bearing finding is that both proposals here reduce to the same single decision. Option 2 isn't the cheaper one: the generated Codex workflow reads secrets.OPENAI_API_KEY, and the action hard-errors before installing anything if it's unset — so a harness: codex override needs exactly the secret option 1 needs. gh secret list --env tend returns only CLAUDE_CODE_OAUTH_TOKEN and TEND_BOT_TOKEN, so nothing here can be trialled until someone puts a key in the tend environment. That's a maintainer call and it's the whole remaining blocker.

What that framing was hiding is that the surface probe doesn't need a key at all — codex exec --help, codex plugin marketplace add, and codex plugin add are all local operations. So the probe run by hand this week can just be a CI job, and #923 makes it one: read the pin out of codex/action.yaml with yq -e, install it, assert the four flags and the Installed plugin root: prefix. It runs on every PR in 13s, so a bump PR now confirms itself.

It also picked up coverage in the other direction that nothing had: plugin.json declares only "skills": "./skills/", so scripts/ landing under the plugin root is a packaging side effect — a change to the manifest or the plugin layout that Codex can no longer install used to surface first in an adopter's job, and now fails here.

One correction to the premise, which the review pass caught: the pin doesn't need to stay on the prerelease line. codex plugin add was alpha-only when the pin was set, but stable 0.147.0 carries it and passes the entire smoke script. So the weekly rule now tracks latest, and two comments in codex/action.yaml still claiming latest was 0.130.0 are fixed. The pin itself is left alone in that PR — moving it changes what every adopter's Codex run installs, and the next weekly run makes that call with the job's confirmation behind it rather than declining as it has been.

Leaving this open until the agent-session half is covered — model selection, model_reasoning_effort, sandbox behavior, and whether the final message reaches --output-last-message still have no verification path without a key.

Verification

Ran the smoke script body end-to-end with no OpenAI credential present, against three versions:

Version	Flags	plugin add parse	skills/ + scripts/
0.131.0-alpha.22 (pinned)	pass	pass	pass
0.147.0 (latest)	pass	pass	pass
0.148.0-alpha.5 (alpha)	pass	pass	pass

Auth gate that blocks option 2 as well as option 1: codex/action.yaml L105-111. The awk parse the job protects: codex/action.yaml L143-145.

Not attempted: any real codex exec session.

[max-sixty]

I don't think we need the alpha any longer?

[tend-agent]

Right — the alpha isn't needed. codex plugin add was the only reason for it, and stable carries it now, so I've bumped codex_version 0.131.0-alpha.22 → 0.147.0 (latest).

I put the bump in #923 rather than its own PR because that PR adds the job that confirms it: test-codex-surface installs whatever is pinned and asserts the CLI surface the action depends on, so the gate and the first bump it gates get reviewed together. It's green against the new pin in 13s. Landing the bump separately would have merged the gate without anything having gone through it.

Verification went a bit further than the last round. --strict-config turns out to validate -c overrides, which matters because model_reasoning_effort is passed that way — a rename would be silently ignored, and --help can't see it. So that's now asserted by the job too, with a negative control so it can't pass vacuously. Running the action's exact argument set gets all the way to a 401, meaning every flag and the gpt-5.5 model string were accepted and auth was the only thing in the way.

The one change in range that touches codex exec's flags is the removal of --full-auto (openai/codex#36054, in 0.147.0). The action passes --sandbox explicitly and never used it.

Leaving this open for the agent-session half — sandbox behavior under a live model and whether the final message actually reaches --output-last-message still need an OPENAI_API_KEY in the tend environment, which is your call. I also switched #923 from Closes #922 to Refs, since its body already said it didn't cover that half.

What the job asserts, and what it can't

Asserted, no credential needed: the four flags the Run Codex step passes still take values; codex plugin add still prints the Installed plugin root: line the action parses with awk; both skills/ and scripts/ land under that root; model_reasoning_effort is still a recognized config field.

The config probes stop at codex's trusted-directory check before any network call, so they add no measurable time:

$ codex exec --strict-config -c 'model_reasoning_effortZZZ="low"' ...
Error loading config.toml: unknown configuration field `model_reasoning_effortZZZ` in -c/--config override

$ codex exec --strict-config -c 'model_reasoning_effort="low"' ...
(config loads; proceeds past config to the trusted-directory check)

Still unreachable here: a successful codex exec session. Everything above confirms the CLI surface, not that an agent run works end to end.