When preferSetupRuntimeForChannelPlugins is active, gateway boot performs
two plugin loads: a setup-runtime pass and a full reload after listen.
The initial pin captured the setup-entry snapshot. The deferred reload now
re-pins so getChannelPlugin() resolves against the full implementations.
Channel plugin resolution fails with 'Channel is unavailable: <channel>'
after the active plugin registry is replaced at runtime. The root cause is
that getChannelPlugin() resolves against the live registry snapshot, which
is replaced when non-primary registry loads (e.g., config-schema reads)
call loadOpenClawPlugins(). If the replacement registry does not carry the
same channel entries, outbound message delivery and subagent announce
silently break.
This mirrors the existing pinActivePluginHttpRouteRegistry pattern: the
channel registry is pinned at gateway startup and released on shutdown.
Subsequent setActivePluginRegistry calls no longer evict the channel
snapshot, so getChannelPlugin() always resolves against the registry that
was active when the gateway booted.
- Add hasAgentReasoningDefault to reasoningExplicitlySet check
This prevents model default from overriding agent's explicit "off"
- Restore !thinkingActive guard for model default fallback
Prevents redundant Reasoning: output alongside internal thinking
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The reasoningDefault was incorrectly skipped when thinking was active.
Thinking controls reasoning depth while reasoning controls visibility -
they should be independent settings.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* test(memory): lock qmd status counts regression
* feat: make /tools show what the agent can use right now
* fix: sync web ui slash commands with the shared registry
* feat: add profile and unavailable counts to /tools
* refine: keep /tools focused on available tools
* fix: resolve /tools review regressions
* fix: honor model compat in /tools inventory
* fix: sync generated protocol models for /tools
* fix: restore canonical slash command names
* fix: avoid ci lint drift in google helper exports
* perf: stop computing unused /tools unavailable counts
* docs: clarify /tools runtime behavior
When OpenClaw restarts under load, the Feishu bot-info probe
(`/open-apis/bot/v3/info`) can exceed the 10-second timeout due to
event-loop contention during channel initialization. This leaves
`botOpenId` empty, causing `checkBotMentioned()` to return `false`
for every group message — silently dropping them all while DMs
continue to work fine.
Two fixes:
1. **Increase startup probe timeout from 10s to 30s** and make it
configurable via `OPENCLAW_FEISHU_STARTUP_PROBE_TIMEOUT_MS` env var.
The previous 10s budget was too tight when multiple channels
(Slack, Discord, Feishu) initialize concurrently.
2. **Graceful degradation in `checkBotMentioned()`**: when `botOpenId`
is unknown, return `true` (assume mentioned) instead of `false`.
This prevents group messages from being silently discarded when the
probe fails for any reason. The trade-off is that the bot may
respond to non-@-mentioned messages temporarily until the next
successful probe, which is far preferable to total silence.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
