fix(test): sanitize both shim recursion-guard variables

devlog/_plan/260817_wave5_execution/080_wave5d_antigravity.md

@@ -217,3 +217,48 @@ That is also the honest answer to "is the sponsorship refusal over-cautious": I
 because reviewing *someone else's* auth change is the maintainer act the label records — but a
 one-line auth fix I wrote and verified myself is exactly the case where a maintainer sponsors
 their own work, so it ships.
+### #1891 landed after all
+
+The hold expired four minutes after I wrote it. The gate bot marked #1891 `review-ready` at
+02:10:50Z — the author rebased onto `9eb3a101a` and ticked all four boxes — so the checklist
+block described above and in my PR comments was accurate when posted and false shortly after.
+
+Merged as `5c66ad205`, verified as an ancestor of `origin/dev`. No file overlap with #1955
+(`src/adapters/` vs `src/oauth/`), so nothing conflicted.
+
+Wave 5D final state: **#1897 and #1891 and the #1955 fix landed; #1889 alone remains**, blocked
+on maintainer sponsorship of an auth surface.
+
+### Full-suite result and the one failure
+
+`bun test --isolate tests` on the merged tree: **12805 pass, 10 skip, 1 fail** across 826 files.
+
+The failure is `Codex autostart shim > Unix shim permits a real Codex process to start a new
+child invocation`, failing with `status 126` — permission denied on exec. It is **environmental
+and pre-existing**, established three ways rather than assumed:
+
+1. it reproduces solo, so it is not cross-test interference;
+2. it fails identically at the campaign baseline `1208bd25c`, which predates every change in
+   this campaign;
+3. all four `test 1/4..4/4` shards passed in the dev CI run for `9eb3a101a`.
+
+**Correction — I had the mechanism wrong, and a reviewer traced the real one.** I wrote that 126
+was the shell's "found but not executable" and that this sandbox blocks execution from a temp
+path. Neither is true: a `chmod 755` script in `mktemp -d` runs fine here, and `/var/folders` is
+not mounted `noexec`.
+
+126 is **opencodex's own recursion-guard sentinel**. This shell exports
+`OCX_SHIM_ACTIVE_DEPTH=1` and `OCX_SHIM_ACTIVE_PID`, because the session itself was launched
+through an installed Codex shim. The test deleted only the pid, so the outer shim started at
+depth 1 instead of 0, the child re-entry reached depth 2, and the guard fired with its
+launcher-loop message — the shim behaving exactly as designed, on a test that meant to start
+from a clean slate. CI is green because CI has no shimmed ancestor, which is what made the
+failure look environmental rather than under-sanitized.
+
+So the fix is a one-line test change, not an environment note: `delete env.OCX_SHIM_ACTIVE_DEPTH`
+beside the existing pid deletion. Left alone it stays red for every developer running the suite
+under an installed shim. Fixed here; the suite is now **12806 pass, 0 fail** locally.
+
+Worth keeping as the lesson: "environmental" was the right disposition and the wrong
+explanation, and a plausible-sounding mechanism in a durable devlog is exactly what misleads
+whoever hits this next.

tests/codex-shim.test.ts

@@ -1043,7 +1043,14 @@ printf '%s\\n' child-codex
       chmodSync(realCodexPath, 0o755);
       chmodSync(shimPath, 0o755);
       const env = { ...process.env, OCX_SHIM_BYPASS: "1" };
+      // Both recursion-guard variables, not just the pid. A developer running this suite from a
+      // shell that was itself launched through an installed shim inherits
+      // OCX_SHIM_ACTIVE_DEPTH=1, so the outer shim starts at depth 1, the child re-entry lands on
+      // depth 2, and the guard exits 126 with the launcher-loop message — the shim behaving
+      // exactly as designed, on a test that meant to start from a clean slate. CI never sees it
+      // because CI has no shimmed ancestor, which is what made this look environmental.
       delete env.OCX_SHIM_ACTIVE_PID;
+      delete env.OCX_SHIM_ACTIVE_DEPTH;
 
       const result = spawnSync(shimPath, ["--help"], {
         encoding: "utf8",