runGatewayAuthHealth() only excluded 'password' and 'token' (with existing
token) from its needsToken check. When gateway.auth.mode was set to
'trusted-proxy' or 'none', doctor --fix would incorrectly:
1. Flag the config as 'missing a token'
2. Prompt to generate a gateway token
3. Overwrite auth.mode to 'token' in openclaw.json
This silently broke trusted-proxy deployments (common in SaaS/reverse-proxy
setups) by replacing the delegated auth mode with token auth.
The fix aligns runGatewayAuthHealth() with the existing
hasExplicitGatewayInstallAuthMode() in auth-install-policy.ts, which
already correctly returns false for 'password', 'none', and 'trusted-proxy'.
Co-authored-by: wujiaming88 <wujiaming88@example.com>
Remove repo-local /landpr and /reviewpr prompt templates so maintainers use the externally maintained workflow instead.
These flows remain available from the external maintainers repo via globally installed Pi skills and prompts.
* fix(pair): render pair qr as media
* fix(gateway): preserve media reply threading
* fix(gateway): harden webchat media replies
* fix(plugin-sdk): keep trustedLocalMedia internal
* docs(changelog): note pair qr media fix
* Update CHANGELOG with recent fixes and enhancements
Updated changelog to include recent fixes and enhancements.
* feat(cli): keep claude cli sessions warm
* test(cli): cover claude live session reuse
* fix(cli): harden claude live session reuse
* fix(cli): redact mcp session key logs
* fix(cli): bound claude live session turns
* fix(cli): reuse claude live sessions on resume
* refactor(cli): canonicalize claude live argv
* fix(cli): preserve claude live resume state
* fix(cli): close dead claude live sessions
* fix(cli): serialize claude live session creates
* fix(cli): count pending claude live sessions
* fix(cli): tighten claude live resume abort
* fix(cli): reject closed claude live sessions
* fix(cli): refresh claude live fingerprints
* fix(cli): stabilize MCP resume hash
* fix: preserve claude live inline resume (#69679)
---------
Co-authored-by: Frank Yang <frank.ekn@gmail.com>
* fix(release-check): assert bundled plugin runtime deps after packed postinstall
Release-check already validates source dist/extensions runtime deps are staged, but runPackedBundledChannelEntrySmoke never re-validates after the packed postinstall runs against the installed tarball. That gap is how 2026.4.21 shipped without @whiskeysockets/baileys in dist/extensions/whatsapp/node_modules, because the source staging passed while the installed layout was left broken.
Re-use collectBuiltBundledPluginStagedRuntimeDependencyErrors against the installed packageRoot right after runPackedBundledPluginPostinstall and fail release-check if any declared runtime dependency is missing from the plugin-local node_modules.
* fix(release-check): check postinstalled dep sentinels at packageRoot/node_modules
Codex review on #70035 caught that collectInstalledBundledPluginRuntimeDepErrors was pointing at dist/extensions/<id>/node_modules, but packed postinstall installs and probes sentinels at packageRoot/node_modules (see dependencySentinelPath in scripts/postinstall-bundled-plugins.mjs). The previous implementation would have falsely failed release-check on healthy packed installs while still missing the original WhatsApp regression.
Reuse discoverBundledPluginRuntimeDeps from postinstall-bundled-plugins.mjs so the release guard uses the exact same dep discovery and sentinel paths the packed postinstall uses. Update the test fixtures accordingly so they model the real install layout.
