From 4254fce00fc6fded927ba4caa435ed392c471928 Mon Sep 17 00:00:00 2001 From: bitkyc08-arch Date: Tue, 18 Aug 2026 11:32:09 +0900 Subject: [PATCH 1/2] docs(devlog): record #1891 landing and the one full-suite failure #1891's hold expired four minutes after I wrote it - the author rebased and ticked all four boxes at 02:10:50Z - so it merged as 5c66ad205. Wave 5D is now down to #1889 alone, blocked on maintainer sponsorship. The full suite on the merged tree is 12805 pass, 10 skip, 1 fail. The failure is the Unix shim autostart test failing with status 126, permission denied on exec, and it is environmental rather than a regression: it reproduces solo, it fails identically at the pre-campaign baseline 1208bd25c, and all four test shards passed in dev CI for 9eb3a101a. The test writes a shim to a temp dir and spawnSyncs it; this sandbox blocks execution from that path. Recorded rather than skipped - the fix is an environment note, not a test change. --- .../080_wave5d_antigravity.md | 29 +++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/devlog/_plan/260817_wave5_execution/080_wave5d_antigravity.md b/devlog/_plan/260817_wave5_execution/080_wave5d_antigravity.md index 3f1b1d8924..b89a2b4d30 100644 --- a/devlog/_plan/260817_wave5_execution/080_wave5d_antigravity.md +++ b/devlog/_plan/260817_wave5_execution/080_wave5d_antigravity.md @@ -217,3 +217,32 @@ 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`. + +The test writes a shim into a temp directory, `chmod 0755`s it, and `spawnSync`s it. 126 is the +shell's "found but not executable" — this sandbox blocks execution from that path. Recording it +rather than skipping it: the right fix is an environment note, not a test change, and it is +outside this campaign's scope. From 75a1b3147ef3a177180e77ca72e885a9122d9f57 Mon Sep 17 00:00:00 2001 From: bitkyc08-arch Date: Tue, 18 Aug 2026 11:36:18 +0900 Subject: [PATCH 2/2] fix(test): sanitize both shim recursion-guard variables The autostart shim test deleted OCX_SHIM_ACTIVE_PID from the child environment but inherited OCX_SHIM_ACTIVE_DEPTH from the parent. A developer running the suite from a shell that was itself launched through an installed Codex shim carries DEPTH=1, so the outer shim started at depth 1 rather than 0, the child re-entry landed on depth 2, and the guard exited 126 with its launcher-loop message. The shim was behaving exactly as designed; the test was starting from a slate it believed was clean. CI never sees this because CI has no shimmed ancestor, which is precisely what made it look like a machine quirk. I had recorded the cause as the sandbox blocking execution from a temp path. That was wrong - a chmod 755 script in mktemp -d runs fine here and /var/folders is not mounted noexec - and a reviewer traced the real mechanism. The devlog now carries the correction, because a plausible-sounding wrong explanation in a durable record is worse than no explanation. --- .../080_wave5d_antigravity.md | 24 +++++++++++++++---- tests/codex-shim.test.ts | 7 ++++++ 2 files changed, 27 insertions(+), 4 deletions(-) diff --git a/devlog/_plan/260817_wave5_execution/080_wave5d_antigravity.md b/devlog/_plan/260817_wave5_execution/080_wave5d_antigravity.md index b89a2b4d30..9086500b74 100644 --- a/devlog/_plan/260817_wave5_execution/080_wave5d_antigravity.md +++ b/devlog/_plan/260817_wave5_execution/080_wave5d_antigravity.md @@ -242,7 +242,23 @@ and pre-existing**, established three ways rather than assumed: this campaign; 3. all four `test 1/4..4/4` shards passed in the dev CI run for `9eb3a101a`. -The test writes a shim into a temp directory, `chmod 0755`s it, and `spawnSync`s it. 126 is the -shell's "found but not executable" — this sandbox blocks execution from that path. Recording it -rather than skipping it: the right fix is an environment note, not a test change, and it is -outside this campaign's scope. +**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. diff --git a/tests/codex-shim.test.ts b/tests/codex-shim.test.ts index 0c73d91d7a..177964e987 100644 --- a/tests/codex-shim.test.ts +++ b/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",