fix(init): explain configuration publication recovery - #3896
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Team Run ID: 📒 Files selected for processing (6)
Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review. 📝 WalkthroughWalkthroughChangesInitial publication diagnostics
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to Initial configuration setup now provides distinct, privacy-safe recovery guidance for permission hardening and hard-link publication failures while retaining the existing no-replacement, complete-file publication behavior. The covered failure paths preserve existing configuration and are ready to merge. Sequence Diagram(s)sequenceDiagram
participant Operator
participant InitWizard
participant ConfigPublication
participant ConfigFilesystem
participant CLI
Operator->>InitWizard: run ocx init
InitWizard->>ConfigPublication: publish initial configuration
ConfigPublication->>ConfigFilesystem: harden temporary file
ConfigFilesystem-->>ConfigPublication: permission or hard-link failure
ConfigPublication-->>CLI: privacy-safe publication diagnostic
CLI-->>Operator: OPENCODEX_HOME recovery guidance
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
|
✅ Deterministic PR hygiene checks passed. |
⏳ DRAFT
What to do
Review readiness checklist
0/4 boxes ticked. This PR stays in draft until every box above is ticked. Hygiene✅ Deterministic PR hygiene checks passed. |
리뷰 · 우선순위 54 / 80이 PR은 #3893을 닫습니다.
src/config/initialize.ts · InitialConfigPublicationError - hardeningFailed를 먼저 보고, 그다음 hardLinkUnavailable, 아니면 일반 “did not finish”입니다. partial write는 권한 실패로 오인되지 않게 테스트했습니다. src/config/initialize.ts · publishInitialConfigNoReplace - harden 전후에만 hardeningFailed를 토글합니다. open 실패나 write/link 실패는 권한 메시지로 위장되지 않습니다. I/O 순서 변경 없음이 핵심입니다. docs-site/.../quickstart.md - 재시도 전 config 디렉터리 검사, 기존 tests/service/init-eof.test.ts - 실제 CLI wizard 경로로 permissions/link/link-residue를 주입해 exit 1·OPENCODEX_HOME·비밀 문자열 비노출·백업 보존을 봅니다. 메인테이너의 판단이 필요한 지점
너의 추천 이 댓글은 grok-bot이 작성했습니다 |
|
Carried into #3941 as the top layer of a manual stack, cherry-picked with The stack puts one change underneath yours: That produced exactly one conflict, the adjacent hunk where your Leaving this open until #3941 lands on |
ea8265a is @parkjs101's work from #3896, cherry-picked with -x onto the portable exclusive-open change. The one conflict was the adjacent hunk this stack was ordered to resolve once: the carried commit inserts hardeningFailed directly after the openSync line that the layer below rewrote. Both survive. A squash landing keeps only the squash message, so the trailer lives here. Co-authored-by: Joonsuh Park <trckstr4422@gmail.com>
… init publication recovery (#3941) Bun on Windows misreads the numeric `O_WRONLY | O_CREAT | O_EXCL` combination and drops the creation bit, so every private config temp write failed with ENOENT: the pid file, config.json, the Codex runtime cache, and the OAuth credential store all route through the two atomic writers, and publishInitialConfigNoReplace hit the same wall before first-run `ocx init` could publish anything. All three call sites now use the portable `openSync(path, "wx", 0o600)` spelling. "wx" maps to O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, so it is behaviorally equivalent here rather than bit-identical: exclusive creation rejects an existing name, including a symlink planted at the temp path, so the added O_TRUNC can never truncate anything. The 0o600 mode, Windows ACL hardening order, identity verification, the single hard-link publication, and descriptor-owned cleanup are unchanged. `ocx init` also now separates a required permission-hardening failure from denied hard-link publication, and both messages name OPENCODEX_HOME as the recovery path. Previously a hardening failure fell into the generic "publication did not finish" message with no direction. Landed as a three-layer manual stack through this tip: #3900 carried, the same spelling applied to initialize.ts, then #3896 carried on top. The one conflict was the adjacent hunk where #3896 inserts hardeningFailed directly after the rewritten openSync line; both survive. Closes #3893. Supersedes #3900 and #3896. Co-authored-by: x3M3x <amroeid1999@gmail.com> Co-authored-by: Joonsuh Park <trckstr4422@gmail.com>
|
Landed on All six of your files are on CI on the integration head passed all 25 jobs with no reruns. Thanks — the recovery guidance is a real improvement over a message that told users only that publication had stopped. |
|
Correction to my closure comment above: I wrote "passed all 25 jobs", which overstates it. The accurate figure for run 34153124187 is 19 successful jobs and 2 skipped, with zero failures or cancellations on the first attempt — 24 successful check runs across that head counting the separate PR-gate workflows. The two skips are the conditional |
|
Landed via #3941 at |
lidge-jun
added
the
landed-via-maintainer
2 participants
Summary
Closes #3893.
When first-run configuration cannot be secured or published,
ocx initnow distinguishes permission-hardening failure from denied hard-link publication and directs the user to a supportedOPENCODEX_HOMElocation. The quickstart explains inspection before retry, preserving existing configuration, and choosing a fresh location on Windows or Unix.The existing write order, private permissions, complete-file publication, no-replacement behavior, and cleanup remain unchanged. CLI integration tests cover permission, link, and cleanup faults, including privacy-safe messages, uncertain-publication warnings, backup preservation, and stopping subsequent setup prompts.
Verification
Windows, Bun 1.4.0; independent branch from
devat522ce5f8c8527d1e6c479a0090af14e390214bcb.bun test tests/config/config-mutation-lock.test.ts tests/service/init-eof.test.ts --test-name-pattern 'failed hardening|unsupported/denied link|publication recovery guidance': 9 passed. These cases failed before the diagnostic change.bun test tests/config/config-mutation-lock.test.ts tests/service/init-eof.test.ts: 38 passed, 3 skipped, 2 failed. Both failures also occur on unchanged522ce5f8c: Windows denies file-symlink creation ininit refuses a directory and a dangling symlink without following either;a swapped temporary symlink is neither written through nor removed as our inodethen lacks the expected residue. No skips or weakened assertions were added.bun run typecheck: passed.bun run privacy:scan: passed.docs-site:bun install --frozen-lockfileandbun run build: passed, 425 pages. Lockfiles unchanged; translated quickstarts checked for conflicting instructions.Physical unsupported-filesystem compatibility is not claimed; the fault tests exercise the existing injected I/O boundary. This draft does not attest full local CI or maintainer security approval. Plan and evidence:
devlog/_plan/260907_init_publication_guidance/010_implementation.md.Checklist
Maintainer review of the initial-config boundary remains pending.
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.
Summary by CodeRabbit
Bug Fixes
Documentation
OPENCODEX_HOMEto select a fresh, writable configuration location on Windows, macOS, and Linux.