fix(postinstall): skip EACCES/EPERM compile cache prune warnings#76362
Conversation
|
Codex review: needs maintainer review before merge. Summary Reproducibility: yes. Source inspection on current main shows both prune catch paths warn unconditionally, and #76353 gives concrete root/non-root global-install steps that hit EACCES under /tmp/node-compile-cache. Real behavior proof Next step before merge Security Review detailsBest possible solution: Land the narrow warning-suppression patch with its regression tests and changelog once exact-head CI and mergeability checks pass. Do we have a high-confidence way to reproduce the issue? Yes. Source inspection on current main shows both prune catch paths warn unconditionally, and #76353 gives concrete root/non-root global-install steps that hit EACCES under /tmp/node-compile-cache. Is this the best way to solve the issue? Yes. Suppressing only EACCES/EPERM in the prune warning path keeps best-effort removal intact and preserves warnings for unexpected errors; a UID-scoped cache path would be a broader product change. What I checked:
Likely related people:
Remaining risk / open question:
Codex review notes: model gpt-5.5, reasoning high; reviewed against 91879ac442d1. |
Response to automated review feedbackReviewer: ClawSweeper Codex verdict on this PR (“needs changes”). Findings addressed
No code/test changes: The review concluded the errno handling and regression tests already match the intent; only the changelog line needed the attribution. Re-verification on the updated branch (
|
bb0768d to
a2d0021
Compare
a2d0021 to
7660e97
Compare
7660e97 to
ffc75af
Compare
ffc75af to
e8f9284
Compare
obviyus
left a comment
There was a problem hiding this comment.
Verified the postinstall compile-cache prune path: EACCES/EPERM cleanup failures now stay quiet while unexpected prune errors still warn.
Maintainer follow-up: rebased onto current main, collapsed the branch to one signed landing commit, fixed the active changelog entry, and added real behavior proof to the PR body.
Local gate: pnpm test test/scripts/postinstall-bundled-plugins.test.ts, formatter check, and pnpm check:changed.
|
Landed on main. Thanks @neeravmakwana. |
Root cause
pruneOpenClawCompileCacheremoves Node version-shaped directories under$NODE_COMPILE_CACHEand under the default$TMPDIR/node-compile-cache. On shared hosts, those bases can belong to another user (for example after a root-owned global install, then manual postinstall as a normal user).rmSync/readdirSyncthen fail withEACCESorEPERM. Postinstall still succeeds, but the catch block always emitted[postinstall] could not prune OpenClaw compile cache, which reads like a correctness problem.Linked issue
Fixes #76353.
Why this fix is safe
Only the diagnostic path changes: permission-denied errors are treated as an expected outcome for shared cache layouts. Removal is still attempted with the same options; unexpected errors continue to warn. No pruning success is asserted for those directories.
Real behavior proof
EACCES.$NODE_COMPILE_CACHEdirectory whose permissions were changed to000so the real filesystemreaddirSyncpath returnsEACCES.node --input-type=moduleimportedpruneOpenClawCompileCachefrom./scripts/postinstall-bundled-plugins.mjs, pointed it at the chmod-000 temp compile-cache directory, and capturedlog.warnoutput.[postinstall] could not prune OpenClaw compile cachefor the permission-denied directory-listing failure.EACCESbehavior at the fixed postinstall prune boundary.Security / runtime controls (unchanged)
No changes to sandboxing, config validation, install trust scanners, credential handling, gateway policies, CLI permissions, or any behavior that replaces runtime enforcement with wording in prompts.
Tests run
pnpm exec oxfmt --check --threads=1 CHANGELOG.md scripts/postinstall-bundled-plugins.mjs test/scripts/postinstall-bundled-plugins.test.tspnpm test test/scripts/postinstall-bundled-plugins.test.tsgit diff --checkpnpm check:changedOut of scope
/tmp(alternative suggested on the issue)