install.sh --cmd clobbers the shared Codex shim (~/.agents/bin/codex)

[fujibee]

Found during the plain-remote doc dogfood (2026-07-30).

What happens

install.sh --cmd <other-name> unconditionally (re)writes ~/.agents/bin/codex, and the generated shim hardcodes the skill dir of the install that wrote it:

export AGMSG_CODEX_SHIM_SCRIPT_DIR=~/.agents/skills/<other-name>/scripts/drivers/types/codex
exec ~/.agents/skills/<other-name>/scripts/drivers/types/codex/codex-shim.sh

The shim path is shared across installs, so the last install wins: after installing a test copy under --cmd agmsg-dfr, every Codex agent launched through the shim dispatches into the test install's drivers (and whatever storage they resolve), while the user believes they are on their production install. Nothing warns at install time — the output says "refreshed Codex monitor shim" as if it were a routine update.

Why it matters

--cmd exists precisely so a second install cannot touch the real one. This is the one place the isolation leaks, and it leaks silently in the most confusing direction (production sessions running test-install code).

Expected

One of:

• per-command shim (~/.agents/bin/codex only for the default install; --cmd installs either skip the shim or write a name-suffixed one and say so), or
• refuse to overwrite a shim owned by a different install without an explicit flag, stating which install owns it.

Recovery today is manual: re-point the two paths in the shim back at the production skill dir (verified working).

[fujibee]

Recurred on 2026-08-02, same mechanism, different install name — install.sh --cmd agmsg-dfc for a second dogfood copy. Recording it because the recurrence is the argument for fixing it: the workflow that hits this is the one we keep repeating.

Blast radius this time, measured: the shim pointed at the new install for 77 seconds (14:11:16 → 14:12:33 local) before it was restored. Nothing routed through it — the new install's teams/ and run/ were still empty afterwards, and nothing under its db/ was newer than the install itself. Those directories are the check worth using: ps cannot see a short-lived process that started and exited inside the window, but a Codex seat that had dispatched through the wrong shim would have left a pidfile in run/ or a registration in teams/.

One detail to narrow the fix. That install wrote to three things shared across installs, and only one of them is winner-takes-all:

path	behaviour
~/.agents/bin/codex	overwritten — last install wins
~/.codex/config.toml	additive; the new roots are prepended and every existing entry is preserved
~/.claude/commands/, ~/.copilot/skills/, …	written under the new command name, no collision

So the isolation leak really is the single file named in this issue. The other two do not need changing, and treating all three as hazards would obscure the one that matters.

Detection, until it is fixed: confirming the target install looks right is not enough — the install that gets damaged is the other one, and its VERSION is untouched. The direct check is:

grep -o '/Users/[^/]*/.agents/skills/[a-z0-9-]*' ~/.agents/bin/codex | sort -u

Recovery is as described above: re-running install.sh --update --cmd <production-name> from the production version's source repoints the shim, and is otherwise a no-op when the source matches what is installed.