fix(e2e-exe-dev): make NANOCLAW_E2E_FORCE_AUTH replace the vault secret

[glifocat]

What changes?

NANOCLAW_E2E_FORCE_AUTH=1 is documented to replace the vault's Anthropic secret. It did not: on the gateway seam the installer ran onecli secrets create again, and on the legacy path setup/auth.ts --create --force also only creates. Each rerun added another anthropic secret for api.anthropic.com, and OneCLI kept using an older one.

Found during the nanocoai/nanoclaw#3980 e2e on 2026-10-01 (VM nc-x3980-eb45, nanoclaw 3290b9bf): after two FORCE_AUTH reruns the vault held 3 anthropic secrets, and the good-key run still got "Invalid API key". Deleting the two older secrets and stopping run 1's still-running agent container made the next run pass.

Secret replacement (e2e-install.sh, seam and legacy paths):

• List the IDs of anthropic secrets for api.anthropic.com before creating.
• Create the new secret as before, then check a new ID is listed. If not, stop and keep the old one, so the vault is never left empty.
• Delete the old IDs, then check none of them is still listed.
• Other secrets are left alone, including anthropic secrets for other hosts.

Stale agent container (FORCE_AUTH=1 only):

• A running agent container keeps the session it started with the old credential, and the ping reuses it. The installer now stops any running container that mounts this checkout's groups/e2e-agent at /workspace/agent.
• Selection is by mount, not name: names changed from nanoclaw-v2-<folder>-<ms> to ncl-<install>-<session>, and a name filter on old refs would also hit other installs on the same Docker daemon. The source is compared in its logical, physical-checkout and fully resolved forms, since Docker keeps the path the host passed.
• Mac runs are unaffected: the e2e-macos driver never forwards FORCE_AUTH, and shared gateways already refuse it.

Plugin 0.12.3; CHANGELOG, catalog and the e2e-exe-dev SKILL.md are updated. Rebased onto nanoclaw-oss-dev-tools#28: the key-file check it added still runs first, then the old IDs are listed.

Validation

• Offline, at b19f0c4 (rebased on main 357a355), python -m unittest discover -s tests with skills/e2e-wizard/requirements.txt installed: 360 tests, one error. That error is test_payload_transport.test_alternate_owning_remote_transports_exact_selected_commit, which also fails on main.
• New installer tests:
  • Seam FORCE_AUTH with two duplicates, an anthropic secret for another host and a generic secret: only the duplicates are deleted, the new secret holds the key file's value, the create happens before the deletes, the stale container is stopped, another checkout's container and a backup container mounting the folder elsewhere are left running, and the ping passes.
  • Create that adds nothing: fails, old secret kept. Delete that exits 0 but keeps the secret: fails.
  • Symlinked group folder with an aliased checkout root: stale container still found.
  • Legacy auth --create --force: old secret replaced.
  • Without FORCE_AUTH: nothing deleted, nothing stopped.
• Mutation checks: against main's e2e-install.sh, 3 FORCE_AUTH tests fail. With docker stop made a no-op, 2 fail (the fake ping answers "Invalid API key" while the stale container runs). Without the physical-checkout candidate, the symlink test fails.
• Codex adversarial review, 5 rounds (the last after the rebase): 13 findings, 8 fixed, 3 refuted, 2 left.
  • Refuted: "another writer could add a secret between list and create". FORCE_AUTH is refused on shared gateways, and the list has no values to match on. Raised twice.
  • Refuted for this PR: check_key_file (from fix(e2e-exe-dev): never score a failure notice as a ping reply #28) reads only the first 4096 characters, while the create sends the whole file. That is on main already and affects every seed, not only FORCE_AUTH.
  • Left: an inspect failure skips that container. That is right when it exited between ps and inspect; a daemon error that bad would also fail the ping. The tests do not prove inference against a real gateway; a live run covers that.
• Live, exe.dev, nanoclaw main 6d8e0c91 (gateway seam, OneCLI), installer from this branch at b19f0c4, one VM (nc-fa29-18c5), 2026-10-01:
  • Run A, fake well-formed API key, fresh VM: exit 2, ping: no_reply, as expected. It left one anthropic secret and a running ncl-… agent container.
  • Run B, same VM, NANOCLAW_E2E_FORCE_AUTH=1 with a good OAuth token: the installer created the new secret, deleted the old ID and stopped the old container (d048000e0105). The ping started a new container and got a real reply. Result: STATUS: pass, PING: ok, verify: success, exit 0. Afterwards the vault held exactly one anthropic secret, the new one.
  • Before this fix, that sequence left 2 secrets and reused the old container, and the good-key run failed with "Invalid API key" (fix(setup): score the agent's failure notice as a failed first chat nanoclaw#3980 e2e).

AI assistance

Written with Claude Code (Opus 5.5); reviewed adversarially by Codex. Ethan reviews before it leaves draft.