PR #74213: fix(plugins): mirror core root-package deps used by core dist code

• Repository: openclaw/openclaw
• Author: maxpuppet
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/74213

Description (problem / solution / changelog)

Summary

Extend `MIRRORED_CORE_RUNTIME_DEP_NAMES` (in `src/plugins/bundled-runtime-deps.ts`) to include the nine root-package runtime dependencies that core dist code imports but that the current allowlist does not mirror into the runtime-deps tree:

• `@agentclientprotocol/sdk`
• `croner`
• `dotenv`
• `jiti`
• `json5`
• `jszip`
• `markdown-it`
• `tar`
• `web-push`

Context

Currently `MIRRORED_CORE_RUNTIME_DEP_NAMES` is just `["semver", "tslog"]`. The dynamic `collectRootDistMirroredRuntimeDeps` scan picks up other imports only when an enabled extension's `package.json` declares the dependency (so `chokidar` works in 2026.4.26 because `extensions/memory-core/package.json` declares it; `jiti` and `markdown-it` work when `matrix` is enabled because `extensions/matrix/package.json` declares them).

But these nine packages are imported by core dist code, not by an extension:

For setups where no enabled extension owns the dependency, the imports never get installed into `~/.openclaw/plugin-runtime-deps/openclaw-<ver>/node_modules`, and Node fails to resolve them when the corresponding code path runs:

``` Cannot find package 'chokidar' imported from ~/.openclaw/plugin-runtime-deps/openclaw-2026.4.25-.../dist/qmd-manager-FuXCtSYP.js ```

(That specific case was fixed in 2026.4.26 because `memory-core` started declaring `chokidar`. The nine above behave the same way.)

Reproduction

Against a vanilla `npm i -g [email protected]`:

```bash cd ~/.npm-global/lib/node_modules/openclaw/dist grep -rh '^import .* from "[^./n]' *.js | grep -oE 'from "[^"]+"' | sort -u

compare each top-level package against .specs[] of:

~/.openclaw/plugin-runtime-deps/openclaw-<ver>/.openclaw-runtime-deps.json

```

The nine listed above appear in dist imports but are not in the manifest `specs`.

Approach

These deps fit the same pattern as the existing `semver` / `tslog` entries: declared in the openclaw root `package.json` and used by core dist code. Adding them to `MIRRORED_CORE_RUNTIME_DEP_NAMES` is the smallest, most consistent fix.

A more durable fix would derive the list from a static analysis of core dist bare-imports during build (or extend `collectRootDistMirroredRuntimeDeps` to treat root `package.json` as a fallback owner) so the allowlist cannot drift as new core deps are added. I left that as a follow-up to keep this PR mechanical and easy to review.

Refs

• Issue: #74199
• Adjacent / closed: #71420 (original locked thread covering the same class of bug; this PR addresses the gap between `MIRRORED_CORE_RUNTIME_DEP_NAMES` and the actual import set)

Test plan

• `pnpm test src/plugins/bundled-runtime-deps.test.ts` — 87 passed
• `pnpm test src/plugins/stage-bundled-plugin-runtime-deps.test.ts src/commands/doctor-bundled-plugin-runtime-deps.test.ts src/infra/package-dist-inventory.test.ts` — all passed
• `pnpm format:check src/plugins/bundled-runtime-deps.ts CHANGELOG.md` — clean
• Verify against a fresh install: install on a host without any of the nine packages currently in the mirror, then trigger code paths (e.g. `openclaw cron list`, push notification path, backup) and confirm no `Cannot find package` errors.

🤖 Generated with Claude Code

Changed files

• CHANGELOG.md (modified, +1/-0)
• src/plugins/bundled-runtime-deps.test.ts (modified, +222/-0)
• src/plugins/bundled-runtime-deps.ts (modified, +14/-1)

PR #74335: fix(codex/app-server): bound startup timeout independently of per-turn timeout

• Repository: openclaw/openclaw
• Author: cathrynlavery
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/74335

Description (problem / solution / changelog)

Summary

• Problem: withCodexStartupTimeout reuses params.timeoutMs (the per-turn budget, often 30 minutes) as the startup ceiling. A deterministic local startup failure — for example a partially extracted plugin-runtime-deps mirror missing a dist/errors-*.js chunk — holds the agent lane for the full turn budget before timing out.
• Why it matters: Observed at durationMs=1799434 on operator gateways with 30-minute turn timeouts, recurring every ~30 minutes overnight and starving every agent of a working model. One bad runtime-deps extraction becomes a 30-minute outage instead of a fail-fast 2-minute restart.
• What changed: Add appServer.startupTimeoutMs (default 120000ms) to CodexPluginConfig and CodexAppServerRuntimeOptions, expose options.startupTimeoutMs on runCodexAppServerAttempt, and use it in place of params.timeoutMs for withCodexStartupTimeout.
• What did NOT change: Per-turn timeoutMs semantics for the actual turn (post-startup) are untouched. requestTimeoutMs for control-plane requests is untouched. The existing startupTimeoutFloorMs floor remains.

Change Type (select all)

• Bug fix

Scope (select all touched areas)

• Gateway / orchestration
• API / contracts (additive only — new optional config + manifest entry)

Linked Issue/PR

• Related #73520 (stale plugin-runtime-deps causes Gateway crash-loop after openclaw update — In Progress; this PR makes the symptom recover quickly even when the underlying extraction issue is not yet fixed)
• Related #74199 (runtime-deps manifest still missing dist bare-imports; PR #74213 merged but v2026.4.26 npm-global still reproduced for our reporter — separate fresh repro to be filed)
• Related #73805 (prewarmConfiguredPrimaryModel blocks 30s on startup — same family of "startup hides behind a wall-clock timeout" bug, but distinct: that one is 30s on prewarm, this one is up to per-turn budget on app-server start)
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: runCodexAppServerAttempt did not have an independent startup timeout. The single withCodexStartupTimeout({ timeoutMs: params.timeoutMs, … }) call (run-attempt.ts:309) reused the per-turn budget for the startup phase. With operator-typical 30-minute turn timeouts, a startup failure (ENOENT on a runtime-deps dist/errors-*.js chunk after a bad upgrade extraction) sat there for ~30 minutes before bubbling out as codex app-server startup aborted.
• Missing detection / guardrail: Codex local startup failures (ENOENT, module-resolution) are deterministic and immediately knowable; the wall-clock timeout was the only escape, and it was set far too long. There was no separate startup ceiling, and the alignment test did not flag a missing knob because no knob existed.
• Contributing context: This compounded with #73520 and #74199 (incomplete plugin-runtime-deps extraction on upgrade) — those bugs created the failure, this bug amplified one occurrence into a 30-minute outage.

Regression Test Plan (if applicable)

• Coverage level that should have caught this: Unit test asserting that startup timing is bounded independently of params.timeoutMs.
• New tests added:
  • extensions/codex/src/app-server/config.test.ts: resolver default (120000ms) and configured override (5000ms) are honored.
  • extensions/codex/src/app-server/run-attempt.test.ts: existing times out app-server startup before thread setup can hang forever test updated to use startupTimeoutMs instead of relying on small params.timeoutMs. New test uses startup timeout independent of per-turn timeout (regression: 30-min hang) sets params.timeoutMs = 30 * 60_000 and asserts startup rejects in <5s when startupTimeoutMs: 1 is supplied.

Architecture / Flow Diagram

Before:
runCodexAppServerAttempt({ timeoutMs: T_turn })
  └─ withCodexStartupTimeout({ timeoutMs: T_turn })  ← startup hidden behind whole-turn budget
        └─ on local ENOENT → pending until T_turn elapses → "codex app-server startup aborted"

After:
runCodexAppServerAttempt({ timeoutMs: T_turn })
  └─ resolveCodexAppServerRuntimeOptions(...) → { startupTimeoutMs: T_startup, ... }   (default 120000)
  └─ withCodexStartupTimeout({ timeoutMs: T_startup })   ← independent ceiling
        └─ on local ENOENT → fail fast at T_startup → "codex app-server startup timed out"

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No

Repro + Verification

Environment

• OS: macOS 25.3.0 (darwin)
• Runtime/container: npm-global install of [email protected]
• Model/provider: openai-codex/gpt-5.5 (configured primary)
• Integration/channel (if any): N/A — gateway-internal failure
• Relevant config (redacted): agents.defaults.model.primary = "openai-codex/gpt-5.5"; tools.exec.security = "full"

Steps

1. Upgrade from v2026.4.25 → v2026.4.26 with openclaw update while the install ends up with an incomplete ~/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-<hash>/dist/ extraction (errors-mgRbu9kw.js missing, observed in our case).
2. Allow agents to attempt turns overnight via cron / heartbeat / channels.
3. Observe gateway.err.log for repeated [agents/harness] Codex agent harness failed; not falling back to embedded PI backend followed by lane task error: durationMs≈1800000 error="Error: codex app-server startup aborted" every ~30 minutes.

Expected

• Codex app-server startup failure surfaces within 60–120s with the missing-module error path so the gateway can either retry, repair, or fall back without holding the lane.

Actual (before this PR)

• Lane held for the full per-turn timeout (~30 min) before reporting "startup aborted." Recurring every ~30 minutes from 03:20 to 06:11 local on the night the issue was reported. Agents had tool_calls=0 for the entire window.

Evidence

• Failing trace before (extracted from operator's gateway.err.log):

  2026-04-29T03:50:40.640-05:00 [agents/harness] Codex agent harness failed; not falling back to embedded PI backend
  2026-04-29T03:50:40.641-05:00 [diagnostic] lane task error: lane=main durationMs=1785599 error="Error: codex app-server startup aborted"
  2026-04-29T05:40:44.785-05:00 [diagnostic] lane task error: lane=main durationMs=1799434 error="Error: codex app-server startup aborted"
  2026-04-29T06:41:32.452-05:00 [plugins] plugin service failed (browser-control, plugin=browser): Cannot find module '~/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-edd222f781b2/dist/errors-mgRbu9kw.js'

• Passing test after:
  • pnpm test extensions/codex/src/app-server/run-attempt.test.ts -t startup → 4/4 startup tests pass.
  • pnpm test extensions/codex/src/app-server/config.test.ts -t startupTimeoutMs → resolver default+override pass.
  • Full files: pnpm test extensions/codex/src/app-server/run-attempt.test.ts extensions/codex/src/app-server/config.test.ts extensions/codex/src/app-server/schema-normalization-runtime-contract.test.ts → 54/54 pass.

Human Verification (required)

• Verified scenarios:
  • Resolver default (startupTimeoutMs = 120000) and explicit configured value (5000) both honored.
  • options.startupTimeoutMs override on runCodexAppServerAttempt takes precedence over resolved config (test: times out app-server startup before thread setup can hang forever).
  • Startup timeout independent of per-turn timeout: params.timeoutMs = 30 * 60_000 does not extend startup ceiling (regression test).
  • pnpm tsgo:extensions clean, pnpm exec oxfmt --check --threads=1 clean on all 8 modified files, manifest alignment test (which compares CODEX_APP_SERVER_CONFIG_KEYS against manifest schema keys and uiHints) still passes after adding startupTimeoutMs to all three.
• Edge cases checked:
  • Existing startupTimeoutFloorMs floor still applies (no behavior change to the floor; Math.max(floor ?? 100, timeoutMs) is unchanged).
  • Three test fixtures that construct CodexAppServerRuntimeOptions directly (not through the resolver) updated with startupTimeoutMs: 120_000 so typecheck stays clean.
• What I did NOT verify:
  • Did not run pnpm check (full prod sweep) or pnpm test (full suite) locally — relied on targeted test files plus extensions typecheck. Maintainers may want CI to run the full gate.

Compatibility / Migration

• Backward compatible? Yes — the new field is optional in CodexPluginConfig; runtime resolver provides a sane default of 120000ms, so existing installs see no behavior change unless they hit a startup failure that previously hung for a long time (in which case they now fail in 2 minutes instead of up to 30+).
• Config/env changes? Yes (additive) — new optional plugins.entries.codex.config.appServer.startupTimeoutMs.
• Migration needed? No.

Risks and Mitigations

• Risk: 120000ms (2 min) is too tight for users on a very slow first-time managed Codex download.
  • Mitigation: The value is configurable via appServer.startupTimeoutMs. The previous behavior (effectively unbounded for the turn budget) is recoverable by setting startupTimeoutMs to a large value. Default chosen because Codex CLI binary is bundled by the runtime-deps mirror, so cold-start should not normally include a download — the situation that motivated this PR.
• Risk: Adding a required field to CodexAppServerRuntimeOptions could break callers constructing the type literally.
  • Mitigation: Repo grep shows production code routes through resolveCodexAppServerRuntimeOptions. The three test fixtures that did construct literals are updated in this PR.

Changed files

• CHANGELOG.md (modified, +1/-0)
• docs/plugins/codex-harness.md (modified, +16/-15)
• extensions/codex/openclaw.plugin.json (modified, +10/-0)
• extensions/codex/src/app-server/config.test.ts (modified, +15/-0)
• extensions/codex/src/app-server/config.ts (modified, +5/-0)
• extensions/codex/src/app-server/run-attempt.test.ts (modified, +21/-4)
• extensions/codex/src/app-server/run-attempt.ts (modified, +2/-1)
• extensions/codex/src/app-server/schema-normalization-runtime-contract.test.ts (modified, +1/-0)

PR #74442: fix(gateway): persist hidden lifecycle session keys

• Repository: openclaw/openclaw
• Author: cathrynlavery
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/74442

Description (problem / solution / changelog)

Summary

• Problem: hidden channel-routed runs could drop sessionKey on lifecycle events before gateway listeners handled them.
• Why it matters: when the terminal lifecycle event lost its session key, gateway session persistence could miss the final status write and leave the session stuck as running.
• What changed: emitAgentEvent() now preserves sessionKey for hidden lifecycle events only, and adds focused regression coverage for hidden lifecycle versus hidden assistant events.
• What did NOT change (scope boundary): hidden assistant/tool traffic is still redacted from Control UI event payloads; no channel-routing, transcript, or session-store schema changes were made.

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 #
• Related #74335
• Related #74341
• Related #74199
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: hidden channel runs (isControlUiVisible: false) stripped sessionKey from all agent events at the shared event bus boundary, including terminal lifecycle events that gateway listeners use to persist session status.
• Missing detection / guardrail: existing tests covered hidden-session chat suppression and visible lifecycle persistence separately, but not the hidden lifecycle event path itself.
• Contributing context (if known): gateway lifecycle persistence in server-chat.ts can recover sessionKey from run context or lookup helpers, but that recovery is weaker than carrying the explicit session key through the lifecycle event itself.

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/infra/agent-events.test.ts
• Scenario the test should lock in: hidden runs must still redact assistant traffic while preserving sessionKey on lifecycle events so downstream gateway listeners can persist terminal session state.
• Why this is the smallest reliable guardrail: the bug is caused at the shared event-bus seam before gateway lifecycle persistence runs, so the smallest stable proof is to assert the event payload shape at that seam.
• Existing test that already covers this (if any): src/gateway/server-chat.agent-events.test.ts already covers hidden-run chat suppression and visible lifecycle persistence separately.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

• Channel-routed sessions that complete a hidden Codex turn now keep their terminal lifecycle session key, allowing gateway session state to persist out of running instead of getting stranded.

Diagram (if applicable)

Before:
[hidden channel run] -> [lifecycle end event drops sessionKey] -> [gateway lifecycle persistence may miss terminal write]

After:
[hidden channel run] -> [lifecycle end event keeps sessionKey] -> [gateway persists terminal session state]

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:

Repro + Verification

Environment

• OS: macOS (operator repro from Knox's machine)
• Runtime/container: OpenClaw v2026.4.26
• Model/provider: Codex app-server via hidden channel-routed sessions
• Integration/channel (if any): Paperclip issue routing and BlueBubbles direct routing
• Relevant config (redacted): hidden channel-routed sessions with isControlUiVisible: false

Steps

1. Run a channel-routed hidden session such as agent:<agent>:paperclip:issue:<uuid> or agent:knox:bluebubbles:default:direct:<phone>.
2. Let Codex finish the turn so the transcript contains a terminal assistant message (stopReason: "stop").
3. Inspect the persisted session entry and gateway diagnostics.

Expected

• The terminal lifecycle event carries enough session identity for gateway listeners to persist a terminal session status and clear the running state.

Actual

• The operator observed entries left at status: "running" with stuck-session diagnostics such as:
• 2026-04-29T09:50:34.939-05:00 [diagnostic] stuck session: sessionId=helm-dev sessionKey=agent:helm-dev:paperclip:issue:8931a100-c86e-4a92-8f65-b29d813bd4d5 state=processing age=565s queueDepth=0

Evidence

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

Human Verification (required)

• Verified scenarios: formatted the diff; ran pnpm tsgo:core, pnpm tsgo:extensions, pnpm tsgo:core:test, pnpm tsgo:extensions:test, pnpm test src/infra/agent-events.test.ts, pnpm test src/gateway/server-chat.agent-events.test.ts, pnpm test src/gateway/session-lifecycle-state.test.ts, and pnpm lint:extensions:bundled; ran an external Codex review that returned ship it.
• Edge cases checked: hidden assistant events still omit sessionKey; visible gateway lifecycle suites still pass unchanged.
• What you did not verify: a live end-to-end repro against Knox's local gateway install after applying this 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
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps:

Risks and Mitigations

• Risk: lifecycle events for hidden runs now include sessionKey on the shared agent-event bus.
  • Mitigation: the change is scoped to stream === "lifecycle" only; hidden assistant/tool traffic remains redacted, and existing gateway hidden-run chat suppression tests still pass.

Changed files

• CHANGELOG.md (modified, +1/-0)
• src/gateway/server-chat.agent-events.test.ts (modified, +9/-1)
• src/gateway/server-chat.ts (modified, +6/-4)
• src/infra/agent-events.test.ts (modified, +44/-1)
• src/infra/agent-events.ts (modified, +8/-1)

PR #74713: fix(plugins): repair configured provider runtime deps

• Repository: openclaw/openclaw
• Author: steipete
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/74713

Description (problem / solution / changelog)

Summary

• centralize bundled runtime-deps selection so doctor, plugins deps, and startup repair include configured provider owners such as anthropic-vertex without staging inactive provider plugins
• remove the duplicate doctor-only packaged plugin selector and document the configured channel/provider staging rules
• atomically refresh materialized root dist chunks in external mirrors so a failed link/copy keeps the previous valid chunk instead of leaving a missing file

Issues

• Refs #74307
• Refs #74199

Validation

• pnpm exec oxfmt --check --threads=1 src/plugins/bundled-runtime-mirror.ts src/plugins/bundled-runtime-root.test.ts src/plugins/bundled-runtime-deps-selection.ts src/plugins/bundled-runtime-deps.test.ts src/commands/doctor-bundled-plugin-runtime-deps.ts src/commands/doctor-bundled-plugin-runtime-deps.test.ts src/plugins/test-helpers/bundled-runtime-deps-fixtures.ts
• pnpm test src/plugins/bundled-runtime-root.test.ts src/plugins/bundled-runtime-deps.test.ts src/commands/doctor-bundled-plugin-runtime-deps.test.ts src/cli/plugins-deps-command.test.ts
• pnpm check:changelog-attributions
• Blacksmith Testbox: OPENCLAW_TESTBOX=1 pnpm check:changed passed before the final rebase; after rebasing onto current main, reran the targeted checks above.

Changed files

• CHANGELOG.md (modified, +2/-0)
• docs/cli/plugins.md (modified, +1/-1)
• docs/gateway/doctor.md (modified, +1/-1)
• src/commands/doctor-bundled-plugin-runtime-deps.test.ts (modified, +54/-22)
• src/commands/doctor-bundled-plugin-runtime-deps.ts (modified, +0/-83)
• src/plugins/bundled-runtime-deps-selection.ts (modified, +91/-1)
• src/plugins/bundled-runtime-deps.test.ts (modified, +44/-0)
• src/plugins/bundled-runtime-mirror.ts (modified, +12/-6)
• src/plugins/bundled-runtime-root.test.ts (modified, +21/-0)
• src/plugins/test-helpers/bundled-runtime-deps-fixtures.ts (modified, +2/-0)