Repository navigation
Conversation
On Dedicated OpenClaw the startup model probe copied the authored primary catalog row and provider fragment. A row authored with the provider prefix (openai/<id>) and its own baseUrl passed admission, but OpenClaw's probe refused to route a known model in that shape, so the Agent failed at deploy while the native worker (which gets the split id) would have worked. The probe now gets the primary row nativeRuntimeConfiguration renders for the worker (split id, checked and normalized endpoint) and that endpoint as the provider default, so the unchecked provider baseUrl never reaches it. Admission renders the native catalog through the probe configuration.
|
🦞👀 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. |
clawsweeper
Bot
added
clawsweeper:intake:bug
|
Codex review: needs maintainer review before merge. What this changesThe native startup probe uses the worker’s rendered primary model row and normalized endpoint. Example: Dedicated OpenClaw selects openai/gpt-5.4 with catalog id openai/gpt-5.4 and a row-specific endpoint.
Review scores
ProductKind: Bug fix · Worth it: Yes · Fix scope: Complete Merge readiness✅ Ready for maintainer review Keep this PR open: it repairs a concrete probe/worker configuration mismatch still present on main, and no introduced correctness defect was found. Priority: P2 Before mergeNone. FindingsNone. Tests
Agent review detailsHow this fits togetherKubernetes Compute turns an admitted Agent configuration and Harness authentication snapshot into worker configuration and startup-probe environment settings; the runtime probe must succeed before the Harness becomes ready. flowchart TD
A[Agent configuration] --> B[Kubernetes Compute admission]
B --> C[Native catalog renderer]
C --> D[Worker model catalog]
C --> E[Primary model probe configuration]
E --> F[OpenClaw startup probe]
F --> G[Checked model endpoint]
Technical reviewBest possible solution: Use the existing native catalog renderer as the single owner of model IDs and endpoints for both worker execution and startup probing. Do we have a high-confidence way to reproduce the issue? Source confirms that main supplies different model-row shapes to probe and worker; the author reports a real-CLI failure for the prefixed known-model case, but this review did not execute it. Is this the best way to solve the issue? The patch is a focused repair because it reuses the worker’s validated representation, preserves reference-refusal ordering, and leaves embedded and Codex paths unchanged. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against 2fccf59d2738. Provenance checked
TestingProof path: in-process harness. SecurityNone. EvidenceWhat I checked:
Likely related people:
Review metrics
LabelsLabel changes:
Label justifications:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
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 Reviewed October 29, 2026, 4:48 PM ET / 20:48 UTC. |
The startup probe row carried its own baseUrl, so the runtime's upfront credential check, which skips rows with a baseUrl, no longer ran on Dedicated OpenClaw, even for the standard api_key shape. Give the probe the rendered row without its baseUrl; the provider default already carries the same checked endpoint (finding 2904).
Problem
On Dedicated OpenClaw with
credential_sourceHarness authentication, a primary model authored asopenai/gpt-5.4with a catalog row whoseidkeeps the provider prefix (openai/gpt-5.4) and whose ownbaseUrldiffers frommodels.providers.openai.baseUrlpasses Compute admission. The startup model probe then fails closed with "Unable to materialize openai/gpt-5.4 for its prepared api-key route", so the Agent fails at deploy. The native worker would run it: it gets the rendered catalog (split model id, checked endpoint).The cause:
harnessProbeConfigurationcopied the authored provider fragment and the authored primary row, not the rownativeRuntimeConfigurationrenders for the worker. OpenClaw's probe cannot route a known model under the prefixed row id when that row's endpoint differs from the provider's.Change
harnessProbeConfiguration(Kubernetes Compute) takes the Harness auth method on Dedicated OpenClaw and gives the probe the primary row asnativeRuntimeConfigurationrenders it for the worker (split model id, normalized fields). The row's checked endpoint becomes the provider default, and the probe row carries nobaseUrlof its own. So the unchecked providerbaseUrlnever reaches the probe, and the runtime's upfront credential check still runs: it skips any row that has its ownbaseUrl.nativeRuntimeConfigurationcall at admission is gone. The rules and messages are unchanged. Reference-setting refusals still come first.No new configuration surface and no compatibility path. Configurations that probe today get the same model and endpoint.
Verification
tests/conformance/kubernetes-compute.test.mjs("native OpenClaw preparation and activation use only outbound Sandbox enrollment") now authors the primary row with the provider prefix. It asserts that the probe gets the worker's rendered primary row without itsbaseUrl, and that the provider default equals the worker row's checked endpoint. The test fails with main'sindex.ts(the probe gets the prefixed authored row) and passes with the fix.credential_source; keepingbaseUrlon the probe row.credential_sourceandapi_key; split, prefixed, slash, alias and padded ids; a fallback listed first; a row-level api; a provider-only endpoint; refusals). Admission is identical to main on all 22. On all 17 accepted shapes, the probe row equals the worker's rendered row withoutbaseUrl, and the provider default equals that row's endpoint.openclaw models status --probein a runtime image with no network, TLS listeners on loopback standing in for every endpoint (api.openai.comincluded), main and this head on all 17 accepted shapes:contextWindowandcost) fails the probe the same way on main: OpenClaw refuses those provider keys in the probe config. That is outside this change.api_keyrow on the official endpoint under another providerbaseUrl). This head reaches the checked endpoint in all four.invalid_api_key(main: three of them).Risks
id,api,name,contextWindow,maxTokens,reasoning,thinkingLevelMap,cost,input; the endpoint as the provider default). Other authored row keys no longer reach the probe, as they never reached the worker.request.*) that the worker does not get.