fix(codex): install local plugin cache during setup

[Retengart]

Summary

• install the Codex plugin cache with codex plugin add claude-mem@claude-mem-local after registering the local marketplace
• copy .install-version into the bundled marketplace plugin root before Codex installs from it
• update the non-TTY install contract tests so local marketplace registration is not treated as a completed Codex install

Root cause

On current Codex CLI, codex plugin marketplace upgrade claude-mem-local is only valid for Git marketplaces. For a local marketplace it fails with:

marketplace `claude-mem-local` is not configured as a Git marketplace

The installer ran that command best-effort, so installs could still report Codex marketplace registration success while codex plugin list showed claude-mem@claude-mem-local as not installed and no active Codex plugin cache existed.

A second related gap is that Codex installs by copying from the bundled marketplace plugin root. That root did not receive .install-version, so a freshly installed Codex cache could inherit a missing marker and hit the runtime not yet set up SessionStart path even though runtime setup had completed elsewhere.

Related older report: #2361.

Verification

• Reproduced locally on Codex CLI 0.142.2: worker readiness was healthy, marketplace was registered, but codex plugin list still showed not installed until codex plugin add claude-mem@claude-mem-local was run.
• Verified local repair: codex plugin list shows installed, enabled; worker readiness returns ready; direct Codex hook replay returns accepted JSON for SessionStart, PreToolUse, and PostToolUse with no suppressOutput on tool hooks.
• bun test tests/install-non-tty.test.ts tests/integration/codex-cli-installer.test.ts tests/setup-runtime.test.ts tests/services/integrations/spawn-contract-windows.test.ts
• npm run typecheck:root
• npm run build

[greptile-apps]

Greptile Summary

This PR updates Codex setup so the local plugin cache is installed during npx install. The main changes are:

• Adds .install-version writing to the bundled marketplace plugin root.
• Replaces the best-effort Codex marketplace upgrade with mandatory codex plugin add claude-mem@claude-mem-local.
• Updates non-TTY install contract tests for local marketplace registration and Codex cache installation.

Confidence Score: 5/5

The changes are focused on Codex setup behavior and are covered by targeted installer and runtime tests.

No issues were identified in the reviewed changes, and the described verification includes relevant non-interactive install, integration, typecheck, and build coverage.

T-Rex Logs

What T-Rex did

• Ran the base TREX harness to install Codex plugins, capturing the base run with TREX_TMP=/tmp/trex-codex/base and command traces that included codex --version, codex plugin marketplace add /tmp/trex-codex/base, and codex plugin marketplace upgrade claude-mem-local, with INSTALL_RETURN_CODE=0 and the stubbed invalid Git marketplace error handled as best-effort.
• Executed the head harness against /tmp/trex-codex/head, reproducing the same command traces with codex --version, codex plugin marketplace add /tmp/trex-codex/head, and codex plugin add claude-mem@claude-mem-local, followed by 'Installed Codex plugin cache.' and INSTALL_RETURN_CODE=0.
• Checked the runtime setup evidence and found that the after-markers log shows runtimeCacheMarker.exists=true, marketplacePluginMarker.exists=true, and freshCopiedCodexMarker.exists=true, with JSON marker content including version, Bun, uv, and installedAt.
• Verified that the marketplace plugin marker is written during runtime setup itself, before the Codex copy/installation steps proceed.

_{Ran code and verified through T-Rex}

_{Reviews (2): Last reviewed commit: "fix(codex): fail when plugin cache insta..." | Re-trigger Greptile}

[rymalia]

@Retengart — #3095 overlaps this directly on the Codex path: same codex plugin add claude-mem@claude-mem-local install and the same removal of the Git-only plugin marketplace upgrade call. Same files too (CodexCliInstaller.ts + tests/install-non-tty.test.ts).

Confirmed our staged code didn't write .install-version at all; yours does, so that's a real fix I was missing. I've folded it into #3095 with one change: rather than seeding the marker into the marketplace plugin root before plugin add, #3095 writes it into the Codex cache dir after tree-sitter provisioning succeeds — so .install-version stays a truthful "runtime ready" signal and can't be copied optimistically for a cache whose provisioning later failed. Same end result for the runtime not yet set up false-positive you fixed, minus the failure window. Credited you in the PR.

#3095 is otherwise a superset on this path (it adds tree-sitter runtime provisioning). Rather than duplicate your work, I'd rather rebase onto #3066 or fold it in with co-authorship — your call. And I'd value your read on whether the marketplace-fallback resolution path also needs a marker, or if the cache-dir write covers the resolutions you were seeing.

[rymalia]

Follow-up: I tested #3095 end-to-end after a fresh local install. The installer wrote .install-version only to the Codex plugin cache, not the marketplace root. A fresh Codex session did not emit the "runtime not yet set up" warning. I repeated the test with the Claude-cache marker temporarily removed to eliminate the fallback path; the warning remained absent. This confirms Codex supplies the installed plugin root to the hook environment, so the post-provision cache marker is sufficient. The marketplace fallback remains a separate defensive-resolution concern, but it does not block the native Codex install path tested here.

[Retengart]

@rymalia Thanks for checking the Codex path end to end.

I am fine with folding #3066 into #3095 with credit/co-authorship if maintainers prefer #3095 as the superset path. The important parts from my side are:

• mandatory codex plugin add claude-mem@claude-mem-local failure propagation, so Codex setup cannot report success without an installed plugin cache;
• a truthful .install-version marker for the active Codex runtime root, so runtime not yet set up does not fire after successful provisioning.

Your cache-after-provisioning placement looks sufficient for the native Codex install path based on the fresh-session verification you posted. I would keep the marketplace-root marker as a defensive fallback concern, not a blocker for #3095.

I also prepared a main sync branch for #3095 here: https://github.com/Retengart/claude-mem/tree/pr3095-main-sync. It resolves the generated bundle conflict against current main and passes the targeted installer/parser/provider verification listed on #3095.