* fix(cron): track and log bestEffort delivery failures, mark not delivered on partial failure
* fix(cron): cache successful results on partial failure to preserve replay idempotency
When a best-effort send partially fails, we now still cache the successful delivery results via rememberCompletedDirectCronDelivery. This prevents duplicate sends on same-process replay while still correctly marking the job as not fully delivered.
* fix(cron): preserve partial-failure state on replay (#27069)
* fix(cron): restore test infrastructure and fix formatting
* fix: clarify cron best-effort partial delivery status (#42535) (thanks @MoerAI)
---------
Co-authored-by: Ayaan Zaidi <hi@obviy.us>
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(telegram): improve error messages for 403 bot not member errors
- Detect 403 'bot is not a member' errors specifically
- Provide actionable guidance for users to fix the issue
- Fixes#48273 where outbound sendMessage fails with 403
Root cause:
When a Telegram bot tries to send a message to a channel/group it's not
a member of, the API returns 403 'bot is not a member of the channel chat'.
The error message was not clear about how to fix this.
Fix:
1. Detect 403 errors in wrapTelegramChatNotFoundError
2. Provide clear error message explaining the issue
3. Suggest adding the bot to the channel/group
* fix(telegram): fix regex precedence for 403 error detection
- Group alternatives correctly: /403.*(bot.*not.*member|bot was blocked)/i
- Require 403 for both alternatives (previously bot.*blocked matched any error)
- Update error message to cover both scenarios
- Fixes Greptile review feedback
* fix(telegram): correct regex alternation precedence for 403 errors
- Fix: /403.*(bot.*not.*member|bot was blocked)/ → /403.*(bot.*not.*member|bot.*blocked)/
- Ensures 403 requirement applies to both alternatives
- Fixes Greptile review comment on PR #48650
* fix(telegram): add 'bot was kicked' to 403 error regex and message
* fix(telegram): preserve membership delivery errors
* fix: improve Telegram 403 membership delivery errors (#53635) (thanks @w-sss)
---------
Co-authored-by: Ayaan Zaidi <hi@obviy.us>
* 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>
* 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
The `createMessageToolCardSchema()` helper returned a bare `Type.Object()`
which TypeBox treats as required when merged into the parent tool schema via
`Type.Object({ card: ... })`. This caused schema validation to reject
media-only sends on Feishu and MSTeams with "must have required property
card", even though the implementation correctly treats card as optional.
Wrap the return value in `Type.Optional()` so the card field is excluded
from the JSON Schema `required` array. Fixes the catch-22 where omitting
card fails validation and including an empty card triggers the runtime
"does not support card with media" guard.
Closes#53697
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Custom providers using `api: "google-generative-ai"` (e.g. a paid
Google tier) resolved in the model picker but failed at runtime with
HTTP 404 because the base URL lacked the required `/v1beta` path
segment and provider normalization was gated on the provider key
being exactly `"google"`.
Two targeted fixes, both keyed on the semantic `api` field rather
than provider name strings:
1. `models-config.providers.ts` — change the normalization gate from
`normalizedKey === "google"` to
`normalizedProvider?.api === "google-generative-ai"` and add
`normalizeGoogleBaseUrl()` to ensure the canonical `/v1beta` suffix.
2. `pi-embedded-runner/model.ts` — apply
`normalizeGoogleGenerativeAiBaseUrl()` in three resolution paths
(`applyConfiguredProviderOverrides`, `buildInlineProviderModels`,
fallback model construction) so the base URL is corrected at
runtime regardless of how the model was discovered.
No changes to name-only call sites (`model-selection`,
`live-model-filter`, `model-forward-compat`); those paths are not
required for custom provider resolution and broadening their provider
checks would incorrectly capture unrelated providers like
`google-antigravity`.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Check routedCounts.final to detect prior delivery
- Skip fallback for ttsMode='all' to avoid duplicate TTS processing
- Use delivery.deliver for proper routing in cross-provider turns
- Fixes#46814 where ACP child run results were not delivered
- invalidate cached Codex CLI credentials when auth.json changes within the TTL window
- skip external CLI sync when the stored Codex OAuth credential is newer
- cover both behaviors with focused regression tests
Refs #53466
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Regeneration-Prompt: |
Current origin/main fails src/cli/program/preaction.test.ts because the
test asserts on process.title directly inside Vitest, where that runtime
interaction is not stable enough to observe the write reliably. Keep the
production preaction behavior unchanged. Make the test verify that the
hook assigns the expected title by wrapping process.title with a local
getter/setter during each test and restoring the original descriptor
afterward so other tests keep the real process object behavior.
The legacy nano-banana-pro skill migration moves the Gemini API key to
models.providers.google.apiKey but does not populate the required baseUrl
and models fields on the provider entry. When the google provider object
is freshly created (no pre-existing config), the resulting config fails
Zod validation on write:
Config validation failed: models.providers.google.baseUrl:
Invalid input: expected string, received undefined
Fix: default baseUrl to 'https://generativelanguage.googleapis.com' and
models to [] when they are not already set, matching the defaults used
elsewhere in the codebase (embeddings-gemini, pdf-native-providers).
Fixes the 'doctor --fix' crash for users who only have a legacy
nano-banana-pro skill entry and no existing models.providers.google.
* add missing autoArchiveDuration to DiscordGuildChannelConfig type
The autoArchiveDuration field is present in the Zod schema
(DiscordGuildChannelSchema) and actively used at runtime in
threading.ts and allow-list.ts, but was missing from the
canonical TypeScript type definition.
Add autoArchiveDuration to DiscordGuildChannelConfig to align
the type with the schema and runtime usage.
* Discord: add changelog for config type fix (#43427) (thanks @davidguttman)
---------
Co-authored-by: Onur Solmaz <2453968+osolmaz@users.noreply.github.com>
* feat(discord): add autoThreadName 'generated' strategy
Adds async thread title generation for auto-created threads:
- autoThread: boolean - enables/disables auto-threading
- autoThreadName: 'message' | 'generated' - naming strategy
- 'generated' uses LLM to create concise 3-6 word titles
- Includes channel name/description context for better titles
- 10s timeout with graceful fallback
* Discord: support non-key auth for generated thread titles
* Discord: skip fallback auto-thread rename
* Discord: normalize generated thread title first content line
* Discord: split thread title generation helpers
* Discord: tidy thread title generation constants and order
* Discord: use runtime fallback model resolution for thread titles
* Discord: resolve thread-title model aliases
* Discord: fallback thread-title model selection to runtime defaults
* Agents: centralize simple completion runtime
* fix(discord): pass apiKey to complete() for thread title generation
The setRuntimeApiKey approach only works for full agent runs that use
authStorage.getApiKey(). The pi-ai complete() function expects apiKey
directly in options or falls back to env vars — it doesn't read from
authStorage.runtimeOverrides.
Fixes thread title generation for Claude/Anthropic users.
* fix(agents): return exchanged Copilot token from prepareSimpleCompletionModel
The recent thread-title fix (3346ba6) passes prepared.auth.apiKey to
complete(). For github-copilot, this was still the raw GitHub token
rather than the exchanged runtime token, causing auth failures.
Now setRuntimeApiKeyForCompletion returns the resolved token and
prepareSimpleCompletionModel includes it in auth.apiKey, so both the
authStorage path and direct apiKey pass-through work correctly.
* fix(agents): catch auth lookup exceptions in completion model prep
getApiKeyForModel can throw for credential issues (missing profile, etc).
Wrap in try/catch to return { error } for fail-soft handling rather than
propagating rejected promises to callers like thread title generation.
* Discord: strip markdown wrappers from generated thread titles
* Discord/agents: align thread-title model and local no-auth completion headers
* Tests: import fresh modules for mocked thread-title/simple-completion suites
* Agents: apply exchanged Copilot baseUrl in simple completions
* Discord: route thread runtime imports through plugin SDK
* Lockfile: add Discord pi-ai runtime dependency
* Lockfile: regenerate Discord pi-ai runtime dependency entries
* Agents: use published Copilot token runtime module
* Discord: refresh config baseline and lockfile
* Tests: split extension runs by isolation
* Discord: add changelog for generated thread titles (#43366) (thanks @davidguttman)
---------
Co-authored-by: Onur Solmaz <onur@textcortex.com>
Co-authored-by: Onur Solmaz <2453968+osolmaz@users.noreply.github.com>
Root cause: Telegram channel monitor captures config at startup before secrets
are resolved and passes it as configOverride into the reply pipeline. Since
getReplyFromConfig() uses configOverride directly (skipping loadConfig() which
reads the resolved runtime snapshot), the unresolved SecretRef objects propagate
into FollowupRun.run.config and crash runEmbeddedPiAgent().
Fix (defense in depth):
- get-reply.ts: detect unresolved SecretRefs in configOverride and fall back to
loadConfig() which returns the resolved runtime snapshot
- message-tool.ts: try-catch around schema/description building at tool creation
time so channel discovery errors don't crash the agent
- message-tool.ts: detect unresolved SecretRefs in pre-bound config at tool
execution time and fall back to gateway secret resolution
Fixes: https://github.com/openclaw/openclaw/issues/45838
When a local run ends with an empty final event while another run is active,
skip history reload to prevent clearing the user's pending message from the
chat log. This fixes the 'message disappears' issue with slow models like Ollama.
1. Narrow loadConfigForInstall() to catch only INVALID_CONFIG errors,
letting real failures (fs permission, OOM) propagate.
2. Assert allow array is properly cleaned in stale-cleanup test.
3. Add comment clarifying version-resolution is already addressed via
the shared VERSION constant.
4. Run cleanStaleMatrixPluginConfig() during install so
persistPluginInstall() → writeConfigFile() does not fail validation
on stale Matrix load paths.
Migrates the Teams extension from @microsoft/agents-hosting to the official Teams SDK (@microsoft/teams.apps + @microsoft/teams.api) and implements Microsoft's AI UX best practices for Teams agents.
- AI-generated label on all bot messages (Teams native badge + thumbs up/down)
- Streaming responses in 1:1 chats via Teams streaminfo protocol
- Welcome card with configurable prompt starters on bot install
- Feedback with reflective learning (negative feedback triggers background reflection)
- Typing indicators for personal + group chats (disabled for channels)
- Informative status updates (progress bar while LLM processes)
- JWT validation via Teams SDK createServiceTokenValidator
- User-Agent: teams.ts[apps]/<sdk-version> OpenClaw/<version> on outbound requests
- Fix copy-pasted image downloads (smba.trafficmanager.net auth allowlist)
- Pre-parse auth gate (reject unauthenticated requests before body parsing)
- Reflection dispatcher lifecycle fix (prevent leaked dispatchers)
- Colon-safe session filenames (Windows compatibility)
- Cooldown cache eviction (prevent unbounded memory growth)
Closes#51806
Document that default-agent heartbeat prompt injection still applies to memory-triggered and triggerless runs while cron remains excluded.
Made-with: Cursor
Ensure repair-mode doctor prompts auto-accept recommended fixes even when running non-interactively, while still requiring --force for aggressive rewrites.
This restores the expected behavior for upgrade/doctor flows that rely on 'openclaw doctor --fix --non-interactive' to repair stale gateway service configuration such as entrypoint drift after global updates.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
When a channel plugin lacks a custom buildToolContext (e.g. Telegram),
the fallback path in buildThreadingToolContext did not set currentThreadTs
from the inbound MessageThreadId. This caused resolveTelegramAutoThreadId
to return undefined, so message tool sends without explicit threadId
would route to the main chat instead of the originating DM topic.
Fixes#52217
Previously, `--at` with an offset-less ISO datetime (e.g. `2026-03-23T23:00:00`)
was always interpreted as UTC, even when `--tz` was provided. This caused one-shot
jobs to fire at the wrong time.
Changes:
- `parseAt()` now accepts an optional `tz` parameter
- When `--tz` is provided with `--at`, offset-less datetimes are interpreted in
that IANA timezone using Intl.DateTimeFormat
- Datetimes with explicit offsets (e.g. `+01:00`, `Z`) are unaffected
- Removed the guard in cron-edit that blocked `--tz` with `--at`
- Updated `--at` help text to mention `--tz` support
- Added 2 tests verifying timezone resolution and offset preservation
Ayaan Zaidi
Andy
ToToKr
Peter Steinberger
Liren Pan
dobbylorenzbot
HCL
SUMUKH
w-sss
Jealous
Josh Avant
dongdong
Quinn H.
Jonathan Jing
Sally O'Malley
VACInc
kevinten10
chocobo9
affsantos
fishking
Tak Hoffman
Vincent Koc
Devin Robison
grassylcao
Kwanghee Park (hugh.k)
Aria
김채완
scoootscooob
giulio-leone
Josh Lehman
Maho Pan
David Guttman
Neerav Makwana
Taras Lukavyi
Mariano
Val Alexander
joelnishanth
Catalin Lupuleti
Sid Uppal
Protocol-zero-0
Rolfy
Devin Robison