Address Codex P1 + Greptile P2:
- Move config validation before the restart attempt so invalid config
is caught in the stop→start path (not just the already-loaded path)
- Derive service.loaded from actual isLoaded() after restart instead
of hardcoded true
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Signed-off-by: HCL <chenglunhu@gmail.com>
After `gateway stop` (which runs `launchctl bootout`), `gateway start`
checks `isLoaded` → false → prints "not loaded" hints and exits.
The service is never re-bootstrapped, so `start` cannot recover from
`stop` — only `gateway install` works.
Root cause: src/cli/daemon-cli/lifecycle-core.ts:208-217 — runServiceStart
calls handleServiceNotLoaded which only prints hints, never attempts
service.restart() (which already handles bootstrap via
bootstrapLaunchAgentOrThrow at launchd.ts:598).
Fix: when service is not loaded, attempt service.restart() first (which
handles re-bootstrapping on all platforms). If restart fails (e.g. plist
was deleted, not just booted out), fall back to the existing hints.
The restart path is already proven: restartLaunchAgent (launchd.ts:556)
handles "not loaded" via bootstrapLaunchAgentOrThrow. This fix routes
the start command through the same recovery path.
Closes#53878
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Signed-off-by: HCL <chenglunhu@gmail.com>
* fix: correct ClawHub URL in system prompt and use streaming download in marketplace
- Fix#54154: Change clawhub.com to clawhub.ai in system prompt
- Fix#54156: Replace arrayBuffer() with streaming pipeline for marketplace
plugin downloads to avoid OOM on memory-constrained devices
* fix: guard marketplace archive stream body
* fix: note marketplace streaming and ClawHub URL (#54160) (thanks @QuinnH496)
---------
Co-authored-by: Li Enying <li.enying@openclaw.ai>
Co-authored-by: Ayaan Zaidi <hi@obviy.us>
* fix(gateway): isolate channel startup failures to prevent cascade
When one channel (e.g., WhatsApp) fails to start due to missing runtime
modules, it should not block other channels (e.g., Discord) from starting.
Changes:
- Use Promise.allSettled to start channels concurrently
- Catch individual channel startup errors without affecting others
- Add startup summary logging for observability
Before: Sequential await startChannel() - if one throws, subsequent
channels never start.
After: Concurrent startup with per-channel error handling - all channels
attempt to start, failures are logged but don't cascade.
Fixes: P0 - WhatsApp runtime exception no longer blocks Discord startup
* fix(gateway): keep channel startup isolation sequential
* fix: isolate channel startup failures (#54215) (thanks @JonathanJing)
---------
Co-authored-by: Ayaan Zaidi <hi@obviy.us>
Add loginctl enable-linger and XDG_RUNTIME_DIR recovery hints to the
generic (non-WSL) systemd unavailable error path, helping users on
SSH/headless servers diagnose and fix the issue without a desktop
session.
Fixes#11805
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
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>
