fix(codex): bound probe cleanup and stabilize verification fixtures

[lidge-jun]

Summary

A Unix install probe can finish with a timeout after its child has already signalled the owned process group. If the parent's single cleanup signal receives EPERM during group exit, preserve that uncertainty while using the existing bounded passive observation. Cleanup completes only after ESRCH; persistent EPERM or a still-live group remains a fail-closed refusal with launcher rollback. No extra termination signals or larger budgets are introduced, and timeout/recursive/descendant probes still refuse installation.

The foundation also carries the independently reviewed replay-fixture correction: one logical conversation reuses one synthetic credential across a forced second boundary, with a separate changed-token isolation control. Production recovery scope is unchanged.

This verified foundation will be inserted beneath the remaining #3692 → #3694 stack. Other A changes are already on dev.

Verification

• Exact failing CI logs were retained; both causes were reviewed independently.
• Replay repair: pinned remote Bun1.4,33 tests passed,typecheck passed; forced per-request credential regeneration fails both expected replay assertions.
• No local suite,typecheck or build executed, per owner instruction.
• Native/scoped cleanup controls, current-head full CI and final independent security review remain pending. No uncertainty is treated as successful termination without disappearance proof.

Checklist

• Scope stays focused and avoids unrelated cleanup.
• Docs or release notes were updated when needed.
• Security-sensitive changes were reviewed for secrets, auth, and unsafe defaults.

Final verification-fixture correction: the local-management child now uses a budget derived from startup plus its bounded requests and the canonical CI watchdog. Fixed phase/count diagnostics identify timeout location without exposing capability values. All exact proxy-bypass assertions remain. Remote19tests/type passed;3500ms startup-delay control passed, old3s guard failed before requests, and deliberate memory misrouting failed the exact proxy-request-count assertion.

Current head: f4bb6daa6b2d2d86a5ba92ce8818b4f5e5c13c67. Full CI: https://github.com/lidge-jun/opencodex/actions/runs/33988432596 . Previous failed head is retained as diagnosis evidence.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

✅ Deterministic PR hygiene checks passed.

[lidge-jun]

리뷰 · 우선순위 70 / 80

이 PR은 지금 dev HEAD 71edeec88(C-lane 5층 #3693 쿼터 diagnostics까지 끝난 상태) 위에서, 남은 A-lane 스택(#3692 affinity → #3694 capabilities) 아래에 깔 검증 기반입니다. 본문은 두 갈래입니다. (1) Unix Codex shim 설치 프로브가 타임아웃으로 정리할 때, 자식 프로세스 그룹이 이미 빠져 나가는 중에 부모가 보내는 한 번의 SIGKILL이 EPERM을 맞으면, 예전에는 그 순간 바로 실패로 끝났습니다. 이제는 EPERM을 잠깐 들고, 기존 1초 수동 관찰로 그룹이 진짜로 사라졌는지(ESRCH)만 확인한 뒤, 사라졌으면 보통의 타임아웃 거부 메시지로, 안 사라지거나 계속 권한이 없으면 예전처럼 fail-closed로 남깁니다. 추가 시그널·더 긴 예산·설치 허용은 없습니다. (2) 테스트만 고친 리플레이 픽스처: 한 논리 대화가 시계 경계를 넘어가도 같은 synthetic credential 헤더를 재사용하게 해서, 강제 두 번째 경계에서 caller 신분이 갈라지던 macOS CI 실패를 막습니다. 프로덕션 복구 범위는 그대로입니다.

현재 HEAD의 src/codex/shim.ts terminateUnixProcessGroup는 process.kill(-groupId, "SIGKILL")가 ESRCH이 아니면 바로 throw했습니다. 그래서 그룹이 동시에 끝나는 짧은 창에서 EPERM이 나면, 이미 죽은(또는 곧 죽을) 그룹인데도 정리 실패로 분류되고, 설치는 롤백되지만 진단이 “타임아웃”이 아니라 “termination EPERM” 쪽으로 흔들릴 수 있었습니다. 고친 코드는 EPERM만 permissionError에 저장하고, 기존 unixProcessGroupAlive 루프를 그대로 돌린 뒤, 그룹이 살아 있으면 저장된 EPERM을 다시 던지고, 사라졌으면 조용히 성공합니다. timeout/recursive/descendant 마커와 “정리 전 그룹이 살아 있으면 설치 거부” 계약은 유지됩니다. 테스트는 native 타임아웃 롤백에다 disappears / persistent EPERM / live-group 세 가지를 같은 fixture 골격으로 붙였고, SIGKILL은 한 번만, 수동 probe는 두 번 이상, 합성 ESRCH을 “진짜 정리됨”으로 치지 않게 native join을 finally에서 합니다.

리플레이 쪽은 tests/server/server-agent-task-recovery-replay.test.ts만 건드립니다. 첫 요청에서 만든 headers를 두 번째 post에 재사용하고, Date.now를 초 경계 +995ms에 고정한 뒤 10ms만 밀어 “새로 만든 미사용 credential은 달라지지만 실제 대화 헤더는 같다”를 증명합니다. 토큰 exp만 다른 isolation 컨트롤도 있습니다. A-lane에서 affinity 프로덕션 코드는 이 PR에 없습니다. 그래서 #3692/#3694보다 먼저 넣는 게 맞고, C-lane OAuth와도 축이 다릅니다. types/config 분할에 직접 무효화되지도 않습니다.

경로/심볼 - src/codex/shim.ts terminateUnixProcessGroup — EPERM 보존 후 기존 1초 passive 관찰; 소멸이면 통과, 잔존/불확실이면 저장된 EPERM 또는 generic nontermination.
경로/심볼 - tests/codex-integration/codex-shim.test.ts — native/disappears/permission/live 네 모드; kill 1회·passive ≥2·launcher 복원·그룹 소멸 증명.
경로/심볼 - tests/server/server-agent-task-recovery-replay.test.ts — 동일 대화 headers 재사용 + 강제 시계 경계 + changed-token isolation.
경로/심볼 - devlog/_plan/260906_a_macos_verification/ · 260906_a_replay_credentials/ — A 기반 계획 문서.
라인 - disappears 모드에서 첫 passive만 EPERM·이후 ESRCH — “한 번 거절 뒤 소멸” 경로; 설치 승인이 아니라 타임아웃 거부 진단만 바뀝니다.
라인 - permission/live 모드 메시지에 [phase=termination; code=EPERM; ...] — 소멸 증명 실패 시 예전 fail-closed 진단 유지.

메인테이너의 판단이 필요한 지점

• 이 기반을 #3692 → #3694 아래에 바로 넣을지, 아니면 exact-head 전체 CI·보안 리뷰를 이 PR에서 먼저 끝낼지(본문도 hosted CI/보안 리뷰를 pending으로 적음).
• 실제 CI에서 본 EPERM이 좀비 그룹 가설과 맞는지(문서는 가설로만 두고 사실로 단정하지 않음) — 진단 문자열만으로 운영 대응이 충분한지.
• 리플레이 픽스처 수정을 affinity PR에 실어 올지, 지금처럼 기반 PR에 먼저 넣을지(자식 retarget 전에 auto-delete 금지 규칙과 맞춤).

너의 추천
exact-head CI와 짧은 보안 확인(추가 시그널 없음·설치 허용 없음·credential 범위 불변)만 보고 dev에 머지하세요. 그다음 #3692/#3694를 이 커밋 위로 retarget. leftover 원본이 있으면 머지 후 Landed via #3708 주석·landed-via-maintainer·close. types/config 분할에 무효화되면 close-don't-rebase.

이 댓글은 grok-bot이 작성했습니다

[lidge-jun]

Integrated as part of the reviewed stack through #3716, dev merge a2f69c8aa60976345740ae6f3d2301f89297328e. This layer's exact head f4bb6daa6b2d2d86a5ba92ce8818b4f5e5c13c67 is an ancestor of dev. The final descendant passed all 24 actual cross-platform CI producers: https://github.com/lidge-jun/opencodex/actions/runs/33991642514. Historical CI remains recorded; the actual integration candidate is #3716.