PR #81414: [codex] fix update restart self-staleness messaging

• Repository: openclaw/openclaw
• Author: BKF-Gitty
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/81414

Description (problem / solution / changelog)

Summary

• Problem: Package updates can succeed and restart onto the new gateway version while the still-running updater process reports a scary future-config warning from the old binary.
• Why it matters: Users can read the warning as a failed PATH or service mismatch even when the package swap and gateway health check are expected and healthy.
• What changed: Package-manager restart health probes now mark their config/auth/service-runtime reads as update self-staleness, including the post-refresh already-healthy probe and retry/recovery probes.
• What did NOT change (scope boundary): Manual gateway service operations from an actually old binary still hit the future-config guard; the actual restart command is not marked with the self-staleness env.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #81394
• Related #
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

External contributors must show after-fix evidence from a real OpenClaw setup. Unit tests, mocks, lint, typechecks, snapshots, and CI are supplemental only. Screenshots are encouraged even for CLI, console, text, or log changes; terminal screenshots and copied live output count. Be mindful of private information like IP addresses, API keys, phone numbers, non-public endpoints, or other private details when providing evidence.

• Behavior or issue addressed: Package-update restart messaging no longer emits the future-config warning during known updater self-staleness health checks.
• Real environment tested: Local OpenClaw PR container mounted to the isolated worktree on macOS.
• Exact steps or command run after this patch: env OPENCLAW_REPO_DIR="/Users/bandaral-saud/Documents/New project/openclaw-update-restart-message" "/Users/bandaral-saud/Documents/New project/openclaw-dev-env/bin/openclaw-shell" env COREPACK_HOME=/home/node/.cache/corepack CI=true pnpm test src/cli/update-cli.test.ts src/cli/daemon-cli/lifecycle-core.config-guard.test.ts
• Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output): Test Files 2 passed (2), Tests 102 passed (102), [test] passed 1 Vitest shard in 26.85s.
• Observed result after fix: Targeted restart-health tests pass, including npm/pnpm/bun package-update health probes with no future-config warning in captured output.
• What was not tested: A live beta package swap on a real installed gateway service was not rerun from this PR branch.
• Before evidence (optional but encouraged): The strengthened test failed before the final code adjustment because the post-refresh already-healthy probe still logged Your OpenClaw config was written by version 2026.5.12-beta.4, but this command is running 2026.5.12-beta.3.

Root Cause (if applicable)

For bug fixes or regressions, explain why this happened, not just what changed. Otherwise write N/A. If the cause is unclear, write Unknown.

• Root cause: During package updates, the parent updater can continue running the previous binary after the package swap while health probes read config/auth/service runtime state written by the updated install.
• Missing detection / guardrail: Restart-health verification did not consistently label those package-update probe reads as update self-staleness, especially the post-refresh already-healthy probe.
• Contributing context (if known): The existing future-config guard is correct for manual destructive service operations and needed to remain intact.

Regression Test Plan (if applicable)

For bug fixes or regressions, name the smallest reliable test coverage that should catch this. Otherwise write N/A.

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/cli/update-cli.test.ts, src/cli/daemon-cli/lifecycle-core.config-guard.test.ts
• Scenario the test should lock in: npm/pnpm/bun package-update restart health probes carry update self-staleness markers and captured output omits the future-config warning.
• Why this is the smallest reliable guardrail: The update CLI seam covers the parent updater restart path without requiring an actual global package swap.
• Existing test that already covers this (if any): Existing future-config guard tests covered manual restart blocking; this PR adds the missing update-path coverage.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

Package-update restart output is less alarming in the known self-staleness path. Manual service operations from old binaries still show the blocking future-config guard.

Diagram (if applicable)

Before:
[package update] -> [new config written] -> [old parent health probe] -> [future-config warning]

After:
[package update] -> [new config written] -> [marked health probe] -> [clear restart output]

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: macOS host
• Runtime/container: OpenClaw PR container, Node 24 image, pnpm 11.1.0 via Corepack
• Model/provider: N/A
• Integration/channel (if any): N/A
• Relevant config (redacted): N/A

Steps

1. Run the targeted update CLI and daemon lifecycle guard tests in the PR container.
2. Verify package-manager update restart-health probes carry update self-staleness env markers.
3. Verify manual gateway restart remains blocked by the future-config guard even with those update env flags set.

Expected

• Targeted tests pass.
• Package-update restart health output omits the future-config warning in the known self-staleness path.
• Manual old-binary service restart remains blocked.

Actual

• Targeted tests passed: 2 files, 102 tests.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: git diff --check; targeted pnpm test src/cli/update-cli.test.ts src/cli/daemon-cli/lifecycle-core.config-guard.test.ts in the isolated worktree container.
• Edge cases checked: package-manager modes npm, pnpm, and bun; manual restart future-config guard with update self-staleness env flags.
• What you did not verify: A live installed-gateway package update run from this PR branch.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No public config/env changes; this uses existing internal update env markers for restart health probes.
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: The self-staleness marker could accidentally hide a real manual old-binary service operation.
  • Mitigation: The marker is scoped to package-manager update health probes with an expected gateway version, and a daemon lifecycle guard test asserts manual restart remains blocked even when the env flags are set.

Changed files

• src/cli/daemon-cli/lifecycle-core.config-guard.test.ts (modified, +25/-0)
• src/cli/update-cli.test.ts (modified, +64/-0)
• src/cli/update-cli/update-command.ts (modified, +20/-4)

PR #81422: fix(update): surface plugin channel fallbacks

• Repository: openclaw/openclaw
• Author: BKF-Gitty
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/81422

Description (problem / solution / changelog)

Summary

• Problem: Beta core updates logged npm plugin channel fallbacks in the install stream, but the final plugin summary did not preserve that mixed-channel state.
• Why it matters: Operators can miss that a configured plugin used @latest because @beta was unavailable.
• What changed: Plugin update outcomes now carry structured channelFallback metadata and both direct plugin updates and post-core summaries emit a concise warning.
• What did NOT change (scope boundary): Install targets, fallback probes, fallback installs, and update semantics are unchanged.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes N/A
• Related #81394
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

• Behavior or issue addressed: Final plugin update output now retains the npm channel fallback warning when a plugin uses @latest because @beta is unavailable.
• Real environment tested: Local OpenClaw repo worktree on macOS, running inside the OpenClaw dev container.
• Exact steps or command run after this patch: In the dev container, ran pnpm test src/plugins/update.test.ts src/cli/update-cli.test.ts to exercise the production post-core summary path and direct plugin update reporting path.
• Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output): Terminal capture from the local OpenClaw dev container:

$ pnpm test src/plugins/update.test.ts src/cli/update-cli.test.ts
✓ |cli| src/cli/update-cli.test.ts (90 tests) 23557ms
  ✓ prints plugin channel fallbacks near the post-core plugin summary 517ms
✓ |plugins| src/plugins/update.test.ts (73 tests) 79ms

Test Files  2 passed (2)
Tests       163 passed (163)
[test] passed 2 Vitest shards in 33.75s

• Observed result after fix: The post-core summary scenario emitted npm plugins: 1 updated, 0 unchanged. followed by plugin channel fallback: lossless-claw used @latest because @beta was unavailable.
• What was not tested: Full live package-manager beta update against the public npm registry; this patch is reporting/data-shape only and does not change registry install semantics.

Root Cause (if applicable)

• Root cause: The fallback was only represented in transient install logging and a local outcome suffix; the durable plugin outcome data did not carry enough structured state for final summaries to repeat it.
• Missing detection / guardrail: No final-summary regression test asserted that channel fallback information survived the plugin update flow.
• Contributing context (if known): Post-core summaries intentionally aggregate plugin outcomes, which made mid-install warnings easy to lose.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/plugins/update.test.ts, src/cli/update-cli.test.ts
• Scenario the test should lock in: npm plugin update falls back from @beta to @latest, and the final summary emits the concise channel fallback warning.
• Why this is the smallest reliable guardrail: The plugin test locks the data shape at the update seam, and the CLI test locks the final operator-visible output.
• Existing test that already covers this (if any): N/A
• If no new test is added, why not: N/A

User-visible / Behavior Changes

Plugin update summaries may now include a concise warning such as plugin channel fallback: lossless-claw used @latest because @beta was unavailable when an npm plugin falls back from a requested channel to @latest.

Diagram (if applicable)

Before:
core update -> plugin @beta unavailable -> install logs mention fallback -> final summary omits mixed-channel warning

After:
core update -> plugin @beta unavailable -> channelFallback metadata -> final summary warns plugin used @latest

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: macOS host
• Runtime/container: OpenClaw dev container, repo pnpm test
• Model/provider: N/A
• Integration/channel (if any): npm plugin update flow simulated by tests
• Relevant config (redacted): N/A

Steps

1. Check the patch with git diff --check.
2. Run pnpm test src/plugins/update.test.ts src/cli/update-cli.test.ts.
3. Inspect the added CLI assertion for the final fallback warning.

Expected

• Plugin fallback metadata is attached to npm beta-to-latest fallback outcomes.
• Final post-core output includes the concise plugin channel fallback warning.
• Existing successful update behavior remains unchanged.

Actual

• git diff --check passed.
• pnpm test src/plugins/update.test.ts src/cli/update-cli.test.ts passed with 2 files and 163 tests.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: unavailable @beta fallback metadata, failed @beta fallback metadata, fallback-second-failure error shape, direct plugin update warning plumbing, and post-core final warning output.
• Edge cases checked: warning deduplication in post-core summary and no ClawHub fallback metadata attachment.
• What you did not verify: full live update against npm registry.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: The new warning could be perceived as extra output.
  • Mitigation: It only emits when fallback metadata exists, uses one concise line per affected plugin, and dedupes final post-core messages.

Changed files

• src/cli/plugins-update-outcomes.ts (modified, +12/-0)
• src/cli/update-cli.test.ts (modified, +43/-0)
• src/cli/update-cli/update-command.ts (modified, +18/-0)
• src/infra/update-runner.ts (modified, +8/-0)
• src/plugins/update.test.ts (modified, +24/-0)
• src/plugins/update.ts (modified, +80/-6)

PR #81425: [codex] fix plugins doctor runtime config warning attribution

• Repository: openclaw/openclaw
• Author: BKF-Gitty
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/81425

Description (problem / solution / changelog)

Summary

Describe the problem and fix in 2–5 bullets:

• Problem: openclaw plugins doctor could load a plugin that calls deprecated api.runtime.config.loadConfig() / writeConfigFile(...), print an anonymous runtime-config-load-write warning, then still report no plugin issues.
• Why it matters: operators could not tell which plugin or path triggered the warning, so the output was noisy instead of actionable.
• What changed: deprecated runtime config warnings now run inside the owning plugin scope and include the plugin id plus source path; warning dedupe is per plugin/API so multiple offending plugins can be identified.
• What did NOT change (scope boundary): no plugin migration, no plugin update fallback-summary work, no restart-health/update-message work, and no change to the deprecated compatibility helpers themselves.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #81394
• Related #
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

External contributors must show after-fix evidence from a real OpenClaw setup. Unit tests, mocks, lint, typechecks, snapshots, and CI are supplemental only. Screenshots are encouraged even for CLI, console, text, or log changes; terminal screenshots and copied live output count. Be mindful of private information like IP addresses, API keys, phone numbers, non-public endpoints, or other private details when providing evidence.

• Behavior or issue addressed: anonymous runtime config deprecation warnings are now attributed to the plugin id/source that triggered them.
• Real environment tested: local OpenClaw worktree in the maintainer Docker dev container on macOS.
• Exact steps or command run after this patch:
  1. git diff --check
  2. pnpm test src/plugins/runtime/runtime-config.test.ts src/plugins/registry.runtime-config.test.ts
  3. pnpm test src/cli/plugins-cli.list.test.ts
  4. pnpm tsgo
• Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output): targeted tests passed locally, including attribution assertions for plugin "legacy-plugin" runtime config.loadConfig() and plugin "legacy-plugin" runtime config.writeConfigFile() plus registry-scope assertions.
• Observed result after fix: runtime config deprecation warnings emitted from plugin-scoped runtime helpers include the plugin id and source path.
• What was not tested: a live third-party plugin installed into a real user config and run through openclaw plugins doctor end-to-end.
• Before evidence (optional but encouraged): issue #81394 reports the previous output as plugin runtime config.loadConfig() is deprecated (runtime-config-load-write); use config.current(). followed by No plugin issues detected.

Root Cause (if applicable)

For bug fixes or regressions, explain why this happened, not just what changed. Otherwise write N/A. If the cause is unclear, write Unknown.

• Root cause: the deprecated runtime config helpers logged through shared runtime code without reading the plugin identity already available in the per-plugin runtime proxy.
• Missing detection / guardrail: tests covered the compatibility warning text, but not plugin-scoped attribution for operator-facing diagnostics.
• Contributing context (if known): the warning cache deduped only by helper name, so even after attribution only the first offending plugin would have been visible without per-plugin dedupe.

Regression Test Plan (if applicable)

For bug fixes or regressions, name the smallest reliable test coverage that should catch this. Otherwise write N/A.

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/plugins/runtime/runtime-config.test.ts, src/plugins/registry.runtime-config.test.ts, src/cli/plugins-cli.list.test.ts
• Scenario the test should lock in: deprecated loadConfig and writeConfigFile warnings include plugin id/source when called under plugin scope, and per-plugin runtime config helpers receive the owning plugin scope from the registry proxy.
• Why this is the smallest reliable guardrail: it exercises the runtime warning formatter and the registry seam that injects plugin-scoped runtime helpers without needing a full external plugin install fixture.
• Existing test that already covers this (if any): src/cli/plugins-cli.list.test.ts still covers the clean doctor success path.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

Deprecated plugin runtime config warnings now include plugin identity and source path when emitted from plugin-scoped runtime helpers.

Diagram (if applicable)

Before:
[plugin calls deprecated config helper] -> [shared warning without plugin id] -> [operator cannot identify source]

After:
[plugin calls deprecated config helper] -> [plugin-scoped runtime proxy] -> [warning includes plugin id/source]

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: macOS host with OpenClaw Docker dev container
• Runtime/container: Node 24 dev container via openclaw-shell
• Model/provider: N/A
• Integration/channel (if any): plugins runtime / CLI doctor diagnostics
• Relevant config (redacted): N/A

Steps

1. Run the runtime config and registry attribution tests.
2. Run the plugins CLI doctor/list tests.
3. Run core tsgo.

Expected

• Deprecated runtime config warnings are attributed to plugin id/source under plugin scope.
• Existing plugins doctor clean-output tests continue to pass.
• Typecheck passes.

Actual

• pnpm test src/plugins/runtime/runtime-config.test.ts src/plugins/registry.runtime-config.test.ts: 2 files passed, 7 tests passed.
• pnpm test src/cli/plugins-cli.list.test.ts: 1 file passed, 9 tests passed.
• pnpm tsgo: passed.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Regression tests now assert warning strings like:

plugin "legacy-plugin" runtime config.loadConfig() is deprecated (runtime-config-load-write); use config.current(). Source: /plugins/legacy-plugin/index.js
plugin "legacy-plugin" runtime config.writeConfigFile() is deprecated (runtime-config-load-write); use config.mutateConfigFile(...) or config.replaceConfigFile(...). Source: /plugins/legacy-plugin/index.js

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: attributed warning formatting, per-plugin warning dedupe, registry proxy scoping for deprecated config helpers, existing CLI doctor/list tests.
• Edge cases checked: duplicate calls from the same plugin warn once; calls from a second plugin warn separately; nested plugin scope does not retain stale pluginSource when only a new plugin id is supplied.
• What you did not verify: a live external plugin installed in a real operator config and run through full openclaw plugins doctor.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: additional warning lines if multiple plugins use the same deprecated helper.
  • Mitigation: warnings are still deduped per plugin/API, and the added lines are actionable instead of anonymous.
• Risk: plugin scoping accidentally drops request-scope fields.
  • Mitigation: withPluginRuntimePluginScope preserves the existing scope via object spread and only updates pluginId/pluginSource.

Changed files

• CHANGELOG.md (modified, +1/-0)
• src/plugins/registry.runtime-config.test.ts (added, +67/-0)
• src/plugins/registry.ts (modified, +21/-1)
• src/plugins/runtime/gateway-request-scope.ts (modified, +21/-3)
• src/plugins/runtime/runtime-config.test.ts (modified, +57/-1)
• src/plugins/runtime/runtime-config.ts (modified, +28/-3)