Repository navigation
fix: stop worker jobs using stale ambient Codex - #4038
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
clawsweeper
Bot
added
clawsweeper:intake:bug
|
Codex review: blocked before merge. What this changesThis PR centralizes verified Codex installation and refreshes worker runtime and certificate pins. Example: A worker already has Codex 0.160.0 on PATH while npm uses a separate global prefix.
Review scores
ProductKind: Bug fix · Worth it: Yes · Fix scope: Complete Merge readiness⛔ Blocked before merge - 1 item remains Keep this PR open: current main still permits stale ambient Codex, and no introduced correctness defect was found in the pinned diff. Priority: P2 Before merge
FindingsNone. Tests
Agent review detailsHow this fits togetherGitHub Actions prepares the runtimes used by security scans, Skill Cards, evaluations, and design audits; those jobs consume queued work or fixtures and produce reports and artifacts. flowchart TD
A[Worker workflow] --> B[Select Node runtime]
B --> C[Install job-local Codex]
C --> D[Verify exact version]
D --> E[Export executable path]
E --> F[Run worker or diagnostic]
Technical reviewBest possible solution: Retain the shared installer and existing security boundaries, then satisfy the recorded acceptance and owner-review gates before landing. Do we have a high-confidence way to reproduce the issue? Current main demonstrably accepts any existing Codex in the Skill Card worker and does not bind global npm installation to subsequent executable selection; no reproduction was executed during this read-only review. Is this the best way to solve the issue? The shared setup action is the best fix location because it owns installation, exact-version verification, and executable selection for every replaced caller; updating version strings alone would preserve the prefix-selection defect. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against d93282970b63. Provenance checked
TestingProof path: shipped entry point. SecurityNone. EvidenceWhat I checked:
Review metrics
LabelsLabel changes:
Label justifications:
Rating scale6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior. WorkflowClawSweeper edits this one comment on every review. Comment HistoryReview history (1 earlier review cycle)
Reviewed October 23, 2026, 10:52 PM ET / October 24, 2026, 02:52 UTC (Revision 2). |
|
@clawsweeper re-review Exact head remains |
|
🦞👀 Re-review progress:
|
clawsweeper
Bot
added
clawsweeper:intake:bug
What Problem This Solves
Fixes worker jobs continuing to execute an older ambient Codex when npm installs the reviewed version into another global prefix, and refreshes the available worker trust inputs.
User Impact
Worker jobs select and verify Codex 0.164.0 from their own job directory. The shared installer selects Node 24.22.1 for npm; stock Bun selectors move to 1.4.4, uv to 0.13.5, and the normal AIG hash lock to certifi 2026.10.23.
Why This Change Was Made
One local setup action owns native CLI installation, exact version verification and the GitHub PATH export for all eight callers. Renderer dependencies retain their separate install step. Existing credentials, branch guards, source pins and publication controls retain their owners.
Evidence
Additional exact-head native AMD64 proof closes the complete installer gate:
b93f6811d3f653f0fb83be4050d857fb9abbb111dfa2ce160563327daff7f306; source-built ClawScan ELFde4fe416e63b605d9a4442cef22e55bd30679256d6b278d4f658a8290152312f. Qualification image IDsha256:4a213773c1980db9de43e93a37da30e0eb062e0c50bdcc21499c30546a426453; evidence archive SHA256180810940c7ac718f2cf24965c93159330752396691ddb6d58bef82c466a48b5.These are native AMD64 installer results, with Ubuntu24 userspace using the guest's Ubuntu26 kernel. They do not establish exact hosted-image identity or deployed delivery. Historical emulation interrupted after71 failures/98passes; only its first timeout was paired, and the other70 remain unattributed. Assertions and deadlines are unchanged.
Policy-required freshly installed benign/malicious real scanner-and-judge acceptance remains incomplete. The bounded full run completed benign static/AIG/SkillSpector stages but failed both judge attempts; the exact consumer correctly rejected the artifact. Malicious input reached600s without a final artifact. Scanner requests observed expected controls and HTTP200 response headers, which do not prove native judge success or completion of timed-out work. TMPDIR diagnosis removed a helper warning but retained native authentication/transport failure markers. The subsequent same-command official Responses positive control returned HTTP401; the fail-closed harness skipped both planned native Codex0.160/0.164 comparisons. Root cause and PR attribution remain unresolved. A valid approved credential/endpoint path and successful exact-head policy acceptance are still needed. No security check, receipt, sandbox, credential boundary or workflow guard was relaxed.
Current-head
openclaw/openclaw-secopsowner approval is also outstanding. No source changes were needed or pushed during this additional validation.Native AMD64 default-HTTP trust gap found; hold for an owning upstream/backend repair. The 63-case exact-ELF wire proof exercised all 14 incident endpoints. With no CA override, seven endpoints reached client Finished followed by large encrypted client data records; rejection of those compromised chains was not enforced. Companion current-endpoint chain captures match the original certificate DER identities and compromised SPKIs; system OpenSSL verification accepts the same seven chains. This disproves the default-backend certificate-rejection claim, without establishing remote authenticated HTTP receipt or successful inference. Native HTTP uses the system/default TLS backend; the selected-CA path forces Rustls. All 28 direct explicit historical-CA cases and all 14 selected-CA WebSocket-to-HTTP fallback cases rejected before Finished. Private trusted-CA HTTP and fallback POST controls passed, unknown/wrong-host private-CA controls rejected, and the public legitimate HTTP control returned an actual HTTP405. No real credential was used.
Exact candidate ELF remains
b93f6811d3f653f0fb83be4050d857fb9abbb111dfa2ce160563327daff7f306; wire export SHA256f8ec1a4c2fcbfa9b3c58d67938bdb4239293f5bf6f11b3c2a421a42c03d65706. Default/no-CA WebSocket-to-native-HTTP fallback is still unproven. The two released predecessor controls selected an explicit historical CA and therefore do not establish predecessor default-native behavior; this gap is not attributed as a new regression introduced by the upgrade. Closure requires an owning default-backend repair qualified through default HTTP, explicit CA and default/no-CA fallback, with legitimate controls. No local trust-policy workaround or security weakening was applied.The later independent auth-only official Responses control also returned HTTP401 outside the product/guest path. This confirms an unavailable current authentication resource, without identifying credential/account/routing/provider cause. The user deferred credential-dependent work; real scanner/judge acceptance remains blocked until that approved resource is restored. SkillSpector's frozen upstream certifi 2026.06.17, compiled Xet/custom old-CA transports, separate proxy binaries and deployed-worker delivery remain distinct open gaps. Python root-data updates do not reject arbitrary explicit old CA stores.
Refreshed upstream default-native trust hold (October 24 UTC)
A fresh official GitHub/npm check still selects stable Codex 0.164.0, source
6aaac694803004a63c6f393d153c96d22521a6b9. The newer0.165.0-alpha.1and inspected main970111f6cb62cc02fe36a82ea7d71b37a2889c97retain the identical completecodex-rs/http-clienttree (a3a9da460393dd54f4b1cef30aef4bd528af0287) and relevant TLS dependency lock entries. No released or maintained owning repair for this default-backend gap was identified. The owning source forces Rustls for a selected CA override and otherwise preserves the default builder.The retained native AMD64 actual-CLI proof, ELF SHA256
b93f6811d3f653f0fb83be4050d857fb9abbb111dfa2ce160563327daff7f306, accepted seven of 14 matching incident chains through client Finished and subsequent encrypted client records on Ubuntu 26's native/default HTTP path. Hold affected default-native uses for an owning repair and actual-artifact default HTTP, default/no-CA WebSocket-to-HTTP fallback, explicit-CA and legitimate HTTPS/private-CA controls. This is an environment/backend-specific demonstrated gap, not an attributed new regression or invalidation of the separate ARM64/explicit-CA proofs above. Provider-authentication status does not establish certificate rejection; credentialed acceptance is tracked separately. No forced-CA workaround, source change or gate waiver is introduced by this status update.