pnpm-lock.yaml not updated

The root package.json now declares @microsoft/agents-hosting as a dependency, but pnpm-lock.yaml was not updated — the root importer section (.) in the lockfile does not yet include this entry. While the package is already resolved in the lockfile as a dependency of the extensions/msteams workspace, pnpm still requires the root importer to be explicitly listed.

In many CI pipelines this manifests as a pnpm install --frozen-lockfile failure like:

ERR_PNPM_OUTDATED_LOCKFILE  Cannot install with "frozen-lockfile" because pnpm-lock.yaml is not up to date with package.json

Please run pnpm install locally to update the lockfile and include pnpm-lock.yaml in this PR.

This is a comment left during a code review.
Path: package.json
Line: 356

Comment:
**`pnpm-lock.yaml` not updated**

The root `package.json` now declares `@microsoft/agents-hosting` as a dependency, but `pnpm-lock.yaml` was not updated — the root importer section (`.`) in the lockfile does not yet include this entry. While the package is already resolved in the lockfile as a dependency of the `extensions/msteams` workspace, pnpm still requires the root importer to be explicitly listed.

In many CI pipelines this manifests as a `pnpm install --frozen-lockfile` failure like:

```
ERR_PNPM_OUTDATED_LOCKFILE  Cannot install with "frozen-lockfile" because pnpm-lock.yaml is not up to date with package.json
```

Please run `pnpm install` locally to update the lockfile and include `pnpm-lock.yaml` in this PR.

How can I resolve this? If you propose a fix, please make it concise.

Update lockfile when adding root dependency

Adding @microsoft/agents-hosting to the root dependencies without a corresponding pnpm-lock.yaml update breaks installs that use --frozen-lockfile (including default CI behavior), because the lockfile importer specifiers no longer match package.json. This causes pnpm install to fail with ERR_PNPM_OUTDATED_LOCKFILE before any build/test steps can run.

Useful? React with 👍 / 👎.

Remove stale fallback return after wrapping spawn in try/catch

Moving result into the try block leaves the existing fallback return result.status === 0; below the try/catch referring to an out-of-scope identifier. In any workflow that type-checks this file (for example the repository's normal check pipeline), this produces Cannot find name 'result' and blocks validation/build before runtime.

Useful? React with 👍 / 👎.

Fix invalid optional type assertion in health status merge

The assertion as Record<string, unknown>? is not valid TypeScript syntax, so this line makes src/commands/health.ts fail to parse/compile (e.g. parser error Unexpected )), which blocks builds and any command path that imports this module. The same malformed assertion appears again later in this function, so the health command cannot be shipped in this state.

Useful? React with 👍 / 👎.

Stop double-probing channels during verbose health checks

Passing probe: doProbe into the new channels.status gateway call causes every account to be probed once in channels.status (see src/gateway/server-methods/channels.ts), and then this function probes the same accounts again in its own per-account loop when doProbe is true. In verbose/probe mode (health with probe: true), this doubles probe work, increasing latency and timeout/rate-limit risk without improving accuracy.

Useful? React with 👍 / 👎.

Preserve existing NODE_OPTIONS when setting heap limit

This spawn call now replaces NODE_OPTIONS instead of inheriting and extending it, which drops any flags the operator already set (for example --require, custom CA settings, or runtime loaders). In environments that rely on those flags, openclaw completion --write-state can fail or run with different behavior only during this doctor path, even though it worked before when process.env was passed through unchanged.

Useful? React with 👍 / 👎.

Read channel account runtime data from the correct payload map

The new merge logic expects account runtime details at channels[channelId].accounts, but channels.status returns account snapshots in a separate channelAccounts[channelId] map (with channels containing only channel summaries). As a result, gwAccounts is always undefined and the loop never backfills running, tokenSource, or timestamps for per-account health, so the intended accuracy improvement does not take effect.

Useful? React with 👍 / 👎.

Delete only the exact cron session key

Using Object.keys(store).find((k) => k.includes(sessionKey) || k.includes(jobId)) can select unrelated sessions, because many valid keys share prefixes/substrings (for example agent:main:main vs agent:main:main:thread:..., or job-1 inside job-10). The subsequent delete s[keyToDelete] then removes whichever matching entry appears first, which can erase the wrong conversation state when cron.remove is called.

Useful? React with 👍 / 👎.

Clean run history even when sessionKey is absent

The run-log cleanup is inside if (sessionKey), but sessionKey is optional on cron jobs and run logs are written per jobId regardless (for example via resolveCronRunLogPath({ jobId }) in src/gateway/server-cron.ts). Jobs created without a session key will therefore never have cron/runs/<jobId>.jsonl removed, leaving stale history files after cron.remove.

Useful? React with 👍 / 👎.

Resolve session cleanup path from the job's agent

Session cleanup always reads the main agent store (resolveStorePath(..., { agentId: "main" })), but cron jobs can run under other agentIds and those session entries are stored in that agent-specific path (for example resolveCronSession resolves store path with agentId). In multi-agent setups, deleting a non-main cron job will miss its actual session entry and the new cleanup silently does nothing.

Useful? React with 👍 / 👎.

Derive cron run-log cleanup path from cronStorePath

This cleanup computes cron/runs from OPENCLAW_HOME/HOME instead of the active cron store location, but the rest of the handler reads run logs via resolveCronRunLogPath({ storePath: context.cronStorePath, ... }). When cron.store or OPENCLAW_STATE_DIR points to a non-default location, cron.remove reports success yet deletes the wrong file path, leaving the real <jobId>.jsonl behind and causing stale run history for removed jobs.

Useful? React with 👍 / 👎.

Parse custom-scheme IPv6 origins without colon splitting

The new custom-scheme branch parses host/port with split(":"), which breaks bracketed IPv6 origins such as tauri://[::1]:18789 (the parsed hostname becomes "["). In that case both host-header fallback and loopback fallback fail (parsedOrigin.host/hostname are wrong), so local Control UI/WebChat connections over IPv6 are rejected even though loopback IPv6 is supported elsewhere.

Useful? React with 👍 / 👎.