fix(cloud-codex): re-pin @commonlyai/mcp to 0.1.9, the newest published version

[lilyshen0722]

Cody has been down for 28 hours because the chart pins an npm version that was never published. One line. This is the fallback fix — read the topology note before merging.

cloud-codex-cody-7b7d7d6f65-v7gj8   0/1   Init:CrashLoopBackOff   322 restarts   28h

Init container codex-tools-installer, current log and --previous, identical:

npm error code ETARGET
npm error notarget No matching version found for @commonlyai/mcp@0.1.10.

The chain, every link dated

08-04 07:52Z  0.1.9 published to npm                        ← still the newest published
08-04 18:16Z  #804 bumps commonly-mcp/package.json → 0.1.10   (in-repo only)
08-04 21:53Z  #810 pins the chart              → 0.1.10       (assumes it's published)
08-04 22:26Z  cody pod created → init crash-loop begins
              ↑ 33 minutes after the pin landed

npm publish never ran between those two PRs. A version bump in package.json is not a publish; it is a promise to publish, and a chart pin is a claim the promise was kept. Neither PR contains the step connecting them.

Verified, not assumed

npm view @commonlyai/mcp versions        →  0.1.7, 0.1.8, 0.1.9
npm view @commonlyai/mcp@0.1.10          →  404          (positive control: 0.1.9 resolves)
grep -rn commonlyMcpVersion k8s/helm/    →  1 occurrence, the template default
                                            (no values override ⇒ this edit is load-bearing)
helm lint                                →  0 failed
helm template … | grep -oE '@commonlyai/mcp@[0-9.]+'  →  @commonlyai/mcp@0.1.9

The load-bearing check is the third one: if a values file overrode commonlyMcpVersion, editing the default would change nothing. It doesn't — and Cody's init error naming 0.1.10 is empirical proof the default is what's in effect.

Why nothing caught it

The pin is a Helm default with no values override, so helm lint and Chart Lint render it fine — a nonexistent version is a syntactically valid string. A pin is a claim about a remote registry that no local lint can evaluate. And npm install --global here carries no || true (correctly — the MCP server isn't optional), so it's fatal rather than degrading. The only witness is an init-container log on one pod that nobody tails.

Topology — read before merging

This restores Cody only via the next deploy. A merged chart default is inert until a helm upgrade.

npm publish from commonly-mcp/ supersedes this entirely and is the better fix: it needs no deploy, and self-heals the currently running pod on its next init retry (~5 min backoff cap). The version is already bumped in-repo; it just needs publishing.

So: if publish lands first, close this PR or convert it to the re-pin. It exists to ride the next Deploy Dev that's leaving anyway — not to justify one on its own.

Why it's open now

Per the pod's pre-registered gate: if a Deploy Dev dispatch becomes necessary for another reason before the publish lands, open the re-pin then so it rides that bus. That condition tripped when #862 merged — a merged, inert one-line fix for a dead public demo on the front page, plus a measured ~3.1-day retention deadline on the replacement room.

The timing is mechanical, not eager: Deploy Dev builds from the dispatched ref, so for this to ride that bus it must be on main before the dispatch. Waiting until a deploy is running would mean missing it by construction.

Not dispatching a deploy — that call belongs to whoever shipped #862, or to Sam.

🤖 Generated with Claude Code