Fix duplicate Codex restore warning after graceful stop

[x3M3x]

Summary

• Track whether graceful proxy shutdown performed shared Codex/Grok teardown itself.
• Prevent ocx stop, ocx update, and related lifecycle commands from attempting a second Codex resume-history restore when the proxy already restored it.
• Preserve caller-side restoration for deferred receipts and hard-kill fallback paths.

Verification

• bun test tests/grok-lifecycle.test.ts tests/process-control-graceful.test.ts (39 pass, 0 fail)
• bun test tests/update-stop-first.test.ts tests/update-*.test.ts (14 pass, 1 skip, 0 fail)
• bun run typecheck
• bun run privacy:scan
• git diff --check
• Full bun run test was also run; it exposed unrelated Windows timing/ACL and spill-publication failures in existing responses-state, retained-root serialization, API-key, and management integration tests.

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.

Review readiness checklist

This PR stays in draft until every box below is ticked. Tick all four boxes once the requirements are met:

• All CI tests are green on my local testing.

• I pushed my PR to the latest dev commit.

• I resolved all correct Codex and CodeRabbit findings.

• My PR is ready for review.

[github-actions]

✅ Deterministic PR hygiene checks passed.

[github-actions]

⏳ DRAFT

• review readiness checklist open (0/4 boxes ticked).

What to do

• Tick all four boxes in the PR description once you're done (currently 0/4).

Review readiness checklist

• ⬜ All CI tests are green on my local testing.
• ⬜ I pushed my PR to the latest dev commit.
• ⬜ I resolved all correct Codex and CodeRabbit findings.
• ⬜ My PR is ready for review.

0/4 boxes ticked.

This PR stays in draft until every box above is ticked.

Hygiene

✅ Deterministic PR hygiene checks passed.

[Ingwannu]

Requesting changes on exact head 0fe7c7dba5d33576a4235bbb9c9b178553aa70f8.

The ownership direction is correct, but the current boolean loses the teardown result that decides whether caller-side recovery is still required.

POST /api/stop deliberately returns HTTP 200 with a typed JSON body from performStopTeardown(). That body can be { success: false, sharedTeardown: "performed" } when native Codex restore or Grok cleanup failed; the process then exits with code 1. stopProxyGracefully() currently discards the body and returns only whether the process exited. On the no-receipt path this PR therefore computes nativeRestoreHandledByProxy = true, includes it in restoreBlocked, and suppresses the caller restore precisely when the proxy reported that its teardown failed. The duplicate warning disappears, but native Codex or the Grok fence can remain pointed at a dead proxy.

Please carry a typed, bounded graceful-stop outcome through stopProxyGracefully() / stopProxy() (or an equivalent narrow seam) and skip caller restoration only after a valid response proves sharedTeardown === "performed" && success === true. A malformed/missing body or success:false must conservatively leave caller restoration enabled. Receipt-backed sharedTeardown:"deferred" and hard-kill fallback must also keep caller restoration enabled; HTTP 409 must remain a refusal with no escalation.

The new test is currently a source-string assertion only. Add behavioral coverage for at least:

1. no receipt + performed/successful proxy teardown → no second caller restore;
2. no receipt + performed/failed proxy teardown → caller restore runs;
3. valid receipt + deferred teardown → caller restore runs;
4. graceful request failure/hard kill → caller restore runs;
5. 409 refusal → no forced stop or shared restore.

This head is also one commit behind current dev, remains Draft, and has the readiness checklist at 0/4 with no full exact-head CI. Once the result boundary is preserved, rebase and request current-head CI. The bug is worth fixing; the blocker is preventing a warning-only cleanup from turning into an unrecoverable skipped cleanup.

[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.}

[lidge-jun]

리뷰 · 우선순위 58 / 80

설명

이 PR은 graceful stop 뒤에 Codex restore 경고가 두 번 뜨는 문제를 고칩니다. 프록시가 공유 Codex/Grok teardown을 이미 했으면, ocx stop / ocx update 같은 호출자가 두 번째 resume-history restore를 시도하지 않게 합니다. deferred receipt나 hard-kill 경로의 호출자 쪽 복원은 그대로 둡니다. HEAD 2f2629f27, 베이스 dev, 브랜치 codex/fix-stop-restore-warning, MERGEABLE, +28/−10 입니다. 파일은 src/cli/index.ts, src/lib/process-control.ts, tests/grok-lifecycle.test.ts 입니다.

지금 HEAD의 stop 경로는 graceful 성공 후에도 호출자가 restore를 한 번 더 시도할 수 있습니다. 사용자는 같은 경고를 두 번 봅니다. 패치는 nativeRestoreHandledByProxy 플래그로 프록시가 처리한 경우를 기억하고, receipt가 없어 프록시가 스스로 복원한 graceful 경로에서는 호출자 restore를 건너뜁니다. receipt가 유효하면 teardown을 이 프로세스가 이어받으므로 호출자 복원이 맞습니다. hard-kill은 언제나 호출자 복원입니다.

remote hub 직후 방향과 직접 맞닿지는 않지만, stop/update 수명은 운영자가 매일 만집니다. #3118 stop history taxonomy, #2888 restart-codex shim 등과 같은 수명 축입니다. types/config 분할 무관합니다. 점수는 58입니다. 실사용자 혼란은 있으나 라우팅/허브 구멍보다는 낮습니다.

라인 src/cli/index.ts nativeRestoreHandledByProxy - stop/update 여러 분기에서 플래그를 세팅합니다. 한 분기만 빼먹으면 중복 경고가 남거나, 반대로 restore가 영구히 빠질 수 있습니다
경로 src/lib/process-control.ts stopProxy - graceful 계약이 receipt/nonce 의미에 의존합니다. 본문 주석(receipt 없음 = 프록시가 복원함)이 코드와 같은지 보세요
경로 tests/grok-lifecycle.test.ts - Grok fence 수명 테스트만 보이면 Codex 중복 경고 회귀가 약할 수 있습니다. process-control-graceful 쪽도 본문이 돌렸다고 하니 CI에 포함되는지 확인하십시오
경로 ocx update - stop-first 경로가 같은 플래그를 쓰는지. update만 두 번 경고가 남으면 반쪽 수정입니다

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

• Codex와 Grok restore를 하나의 플래그로 묶는 것이 맞는지, 한쪽만 처리된 혼합 실패가 있는지
• 문서/릴리스 노트에 "중복 restore 경고 제거"를 넣을지. 체크리스트에 docs는 비어 있습니다

너의 추천
focused lifecycle 테스트가 초록이면 머지해도 됩니다. remote hub 후속(#3168)과 계정 핀(#3166)보다 우선순위는 낮습니다. 라벨은 바꾸지 않습니다.

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

[lidge-jun]

Landed via maintainer rebase #3187. Your commit was cherry-picked onto current dev with author credit preserved, no conflicts.

Focused verification on the rebase head: grok-lifecycle, process-control-graceful and update-stop-first together report 54 pass, 0 fail. The Windows timing/ACL and spill-publication failures you saw in the full run are the known environment-dependent set, not yours.

Good catch on preserving caller-side restore for deferred receipts and the hard-kill fallback — those are exactly the paths where the proxy never got to do the teardown, and a blanket skip would have traded one bug for a worse one.