Behavior addressed: The codex-cli metadata branch no longer calls process.exit(0) immediately after writing stdout, and it still emits exactly one unsupported-backend JSON object.
Real environment tested: Local OpenClaw source checkout on macOS with Node/tsx.
Exact steps or command run after this patch: pnpm test test/scripts/print-cli-backend-live-metadata.test.ts test/scripts/docker-build-helper.test.ts; node --import tsx scripts/print-cli-backend-live-metadata.ts codex-cli | python3 -c 'import sys,json; print(json.load(sys.stdin)["provider"])'; autoreview --mode branch --base origin/main --no-web-search.
Evidence after fix: Focused tooling test shard passed 2 files / 23 tests; direct pipe parse printed codex-cli; autoreview reported no accepted/actionable findings; PR status rollup was clean.
Observed result after fix: stdout is parseable as a single JSON payload and the normal metadata path is skipped for codex-cli.
What was not tested: Live provider metadata paths beyond the focused existing test coverage.
Co-authored-by: Iftekhar Uddin <ifuddin3@gmail.com>
Replays #84749 because the contributor fork branch became conflicted and was no longer maintainer-writable.
Co-authored-by: TeodoroRodrigo <rodrigoteodoro.90@gmail.com>
* fix(scripts): include ui:build in build-all full and ciArtifacts profiles
Closes#85206.
scripts/build-all.mjs only ran ui:build via a separate `pnpm ui:build`
command. Because `pnpm build` invokes tsdown which removes `dist/`,
a backend rebuild silently deletes any previously generated
dist/control-ui assets, leaving the gateway to serve the
"Control UI assets not found" message at startup. Documentation and
startup auto-repair masked the bug at the worst possible time
(LaunchAgent readiness / remote recovery) instead of guaranteeing the
build artifact contract.
This change adds ui:build as a build-all step after
copy-export-html-templates and before write-build-info, and includes
it in the full and ciArtifacts profiles. Minimal backend dev profiles
(gatewayWatch, cliStartup) keep their existing fast-loop step lists
and do not run ui:build.
Regression coverage:
- ciArtifacts step list assertion updated to match the new ordering.
- Three new resolveBuildAllSteps assertions: ui:build is in full and
ciArtifacts and runs after tsdown/runtime-postbuild-stamp and before
write-build-info; ui:build is excluded from gatewayWatch/cliStartup;
ui:build cache outputs declare dist/control-ui.
* fix(scripts): leave ui:build uncached so dist/control-ui never restores stale build IDs
ClawSweeper review on #86010 flagged that the original ui:build cache only
hashed ui/, scripts/ui.js, and scripts/lib/copy-assets.ts, but
ui/vite.config.ts also reads package.json plus git HEAD and the
OPENCLAW_CONTROL_UI_BUILD_ID/OPENCLAW_VERSION env vars to embed a build ID
into the app and service worker. A file-input cache signature cannot
exactly invalidate those metadata sources, so a warm build-all hit could
restore a previously generated dist/control-ui after tsdown clears dist
and ship stale service-worker/app cache metadata.
Leaving the step uncached keeps the contract simple: every pnpm build
re-runs Vite, which is fast for the Control UI bundle and matches the
existing behavior of every other un-cached build-all step. Backend-only
profiles (gatewayWatch, cliStartup) are still unchanged.
Tests:
- Updated the ui:build cache assertion to require step.cache to be
undefined and explain the metadata-input reason.
- Existing presence/order/exclusion assertions for ui:build are unchanged
and still cover the full and ciArtifacts profile contract.
* fix(scripts): keep ui build fallback pnpm-free
---------
Co-authored-by: 1052326311 <1052326311@users.noreply.github.com>
Co-authored-by: Peter Steinberger <steipete@gmail.com>
