Promote Cloud images with the Codex hook-trust fix and latest agents

Merged
AU
23d ago
+795-42

Summary

Codex on cmux Cloud machines still opens with "Hooks need review: 11 hooks are new or changed" after #20482. That PR fixed the trust cmux-tui's codex wrapper passes to Codex, but a machine runs the cmux-tui its image baked. Every default image bakes cmux-tui f9d8ad69, from before the fix, and nothing on a running machine upgrades its daemon on its own. The image verifier didn't catch this for two reasons: it launched codex directly, never through the wrapper a cmux pane uses, and Codex draws its composer before the hook-review dialog, so a screen probe passes either way.

This PR promotes a new image whose cmux-tui (28e864017f, includes #20482) gets Codex's trust, together with the latest coding agents. It also makes the image verifier catch the problem and corrects the docs. Merging it is the production image promotion (#20532, merged into this branch).

Old default (f9d8ad69 bake)This bake
cmux-tuif9d8ad69 (before #20482)28e864017f (includes #20482)
Claude Code2.1.2672.1.299
Codex0.154.00.162.1
OpenCode1.18.301.19.0
pi0.85.11.2.0
agent-browser0.37.10.39.1

Pins are npm latest (devbox:pins:check --write); epoch 2026-10-14-r1.

New snapshots (desktop and base share each size): sm sh-ab014406eece40d49716f044c0880c85, md sh-5deafe1e0ff741649ebea308d215671a, lg sh-4827326f9dac4db9be5e85b72ccfb96b, lgx sh-982bfc25df67499f878d3340387d71eb, xl sh-9c49530ebf994b508677ffb0b850654e, 2xl sh-7ab2d629dc9347e097eb1ea764f53db3.

  • Verifier: codex-pane-hooks-trusted records the exact argv the cmux-tui codex wrapper hands Codex, then asks Codex itself (codex <argv> app-server → hooks/list for the work home) and requires every hook to be trusted. "Hooks need review" also joins the Codex first-run gate texts.
  • Docs: the devbox README now states the one source of a new machine's image: the manifest's defaultForKind rows, read only through resolveVmImage. It also covers the fork/restore/template exception and how cmux-tui reaches running machines. The Dockerfile header, the VM README and .env.example claimed the driver installs or heals cmux-tui at create/attach and that a deployment reads CMUX_VM_CMUX_TUI_MANIFEST_URL. Neither is true; only the bake, verify and fleet-upgrade scripts do.

Where a new machine's image comes from

Every default create path resolves through the manifest's defaultForKind rows: the Mac New Machine sheet, iOS, cmux vm new, POST /api/vm, and vm base open/reset. None sends an image id unless a person passes --image, and there are no env, team, plan or user image pins. Fork, restore and templates boot the user's own snapshot and keep its cmux-tui; like every running machine, they take a new cmux-tui only through web/scripts/upgrade-fleet-cmux-tui.ts.

Relates to #20482.

Testing

  • Repro on a running machine (cmux-tui f9d8ad69, codex-cli 0.162.1): codex through the pane wrapper shows "Hooks need review / 11 hooks are new or changed". hooks/list reports 11 trusted persistent hooks and 11 untrusted /<session-flags>/config.toml:* hooks.

  • Same machine after upgrade-fleet-cmux-tui.ts --commit 28e864017f… (OK upgraded terminals=2->2): no prompt, and 22 of 22 trusted.

  • The new check, rendered as the verifier runs it, on that machine: red against the saved f9d8ad69 binary (exit 1, 11 untrusted), green against 28e864017f (codex-pane-hooks-trusted-ok 22).

  • verify-devbox-image.ts freestyle sh-cf786326… (bake with cmux-tui 28e864017f, Codex 0.154.0) with this verifier: ALL CHECKS PASSED, including codex-pane-hooks-trusted-ok 22.

  • python3 web/tests/devbox-codex-hook-trust-test.py: 5 passed (including injected hooks missing while the rest are trusted). In bun test tests/vm-devbox-image.test.ts the new test passes. Three existing agent-config tests fail only on this Mac, whose python3 3.9 lacks tomllib; CI's Linux runner has it.

  • bun run devbox:manifest:check: ok. The docs edits don't change the source digest.

  • bun run devbox:promote -- freestyle from this branch (CMUX_BAKE_ALLOW_BRANCH=1, cmux-tui pinned to 28e864017f): bake → verify-devbox-image.ts ALL CHECKS PASSED, including codex-pane-hooks-trusted-ok 22 (Codex 0.162.1 through the cmux-tui pane wrapper: every hook trusted, no review) → sizes sm…2xl derived and re-booted → manifest written.

  • bun run devbox:manifest:check: 12 validated defaults, all baked from this checkout's devbox sources.

  • End to end on a tagged dev build (cmux DEV pr-20532-cloud-agents-v2, fleet job f2fd21de39faa5343c0d41fb, dev backend serving this branch's manifest):

    • cmux vm new --focus false, the default path with no image, kind or size, created vm-3b1eefe1… on sh-5deafe1e0ff741649ebea308d215671a, this ladder's md row.
    • Inside it: /etc/cmux/image-stamp reads 2026-10-14-r1; cmux-tui is 28e864017f; Claude Code is 2.1.299, Codex 0.162.1, OpenCode 1.19.0, pi 1.2.0 and agent-browser 0.39.1.
    • The pane hook-trust probe reports codex-hooks-trusted-ok 22.
    • In the machine's own cmux terminal, codex started through the cmux wrapper (--enable hooks -c hooks…, team mode). It sat at the composer for 20 s with no "Hooks need review". In own-sign-in mode it stops at Codex's ChatGPT sign-in first, which is unrelated to hooks.

  • After merge and deploy: a production machine created through the default path still has to be checked.

Changelog

Fixed: Codex on new cmux Cloud machines starts without asking to review cmux's hooks, and new machines ship the latest Claude Code, Codex, OpenCode, pi and agent-browser

Proof

Guest-side CLI evidence above; no Mac UI change.

🤖 Generated with Claude Code