* fix(ios): honor speech locale for system voice
* chore(ios): refresh talk locale i18n inventory
* fix(ios): fall through unavailable system voices
* chore(ios): refresh talk locale i18n inventory
---------
Co-authored-by: Colin Johnson <colin@solvely.net>
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* docs: add local speech TTS setup
* docs: clarify local HTTP release requirement
* docs: require Speech Swift v0.0.23
* docs: use released speech-core Windows package
* docs: use current TTS config in local recipes
Co-authored-by: ivan-digital <root@ivan.digital>
---------
Co-authored-by: ivan-digital <root@ivan.digital>
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* docs: link macOS onboarding pages to app download
Add download handoff to both macOS app onboarding entry points so
first-time users can reach the app before following first-run steps.
- onboarding.md: add <Tip> linking to /platforms/macos#download
- onboarding-overview.md: update comparison table Command row and
macOS section opening sentence with download link
Closes#111338
* docs: tighten macOS download handoff
Co-authored-by: WangYan <wang.yan29@xydigit.com>
---------
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* docs: recommend Node 26 in quickstart, landing, and platform install docs
- Problem: the user-facing quickstart (docs/start/getting-started.md), landing
page (docs/index.md), and Linux/macOS platform install docs still mark
Node 24 as the recommended default, contradicting maintainer PR #114399
('recommend Node 26 as the OpenClaw runtime') and the installer default
(scripts/install.sh NODE_DEFAULT_MAJOR=26, openclaw.mjs
RECOMMENDED_NODE_MAJOR=26). Users following the quickstart pick a slower,
heavier runtime against the project's stated recommendation.
- Fix: align the 4 missed user-facing install surfaces to 'Node 26
recommended', matching the phrasing already in docs/install/node.md,
docs/install/index.md, docs/install/ansible.md, docs/install/bun.md, and
docs/help/faq-first-run.md. Leave docs/start/setup.md (the source/dev
workflow where CI pins Node 24) unchanged on purpose.
- Verification: docs-only diff reviewed; supported-version floors
(22.22.3+/24.15+/25.9+) unchanged; consistent across all install surfaces.
* docs: complete Node 26 installation guidance
Co-authored-by: Santhi Prakash <b.santhiprakash@gmail.com>
---------
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* fix(state): name the refusing install in schema and exec-approval refusals
The newer-schema refusal told operators not to downgrade and to upgrade
OpenClaw, neither of which is actionable when two builds share one release
version string. It now names the install root that refused, both schema
versions, and warns that a linked source checkout reports its git HEAD even
when its built dist is older.
The exec-approvals gate told operators to run `openclaw doctor --fix` without
naming the state directory, so a bare invocation repaired the default root
while the scoped install stayed blocked. Both the TypeScript gate and its
Swift sibling now scope the command to the blocked state directory.
Refs #115008
* fix(gateway): name the refusing install in the startup schema refusal
* fix(mac): keep the exec-approvals gate message buildable on iOS
* fix(exec-approvals): shell-quote the state directory in the repair command
* fix(exec-approvals): state the repair directory in prose so every shell can follow it
* fix(channels): make channel health reflect inbound ingress, not just the transport
`connected` is a transport signal, so a channel holding a healthy socket while its
durable ingress queue is unavailable evaluated as `health: healthy` and admitted
nothing. On a production gateway that hid 26+ hours of completely dead inbound Slack
behind `connected, bot:config, app:config, health:healthy`; outbound kept working,
which is what kept the transport looking fine.
Add inbound admission as its own health dimension rather than overloading `connected`
(deliberately tri-state since 30fda068aa, and 17 of 27 channel plugins depend on
absent meaning "no transport signal"). The shared ingress monitor now rethrows a
typed ChannelIngressUnavailableError when it cannot open its durable queue, the
channel supervisor records that as `ingressUnavailable` on the account, and
`evaluateChannelHealth` reports `ingress-unavailable` ahead of every lifecycle
window. Absence stays "unknown", never "fine", so socketless and simply quiet
channels are untouched; no traffic-staleness heuristic is introduced.
The health monitor deliberately does not restart such an account. A denied or
unusable ingress queue is a capability/config failure that a restart cannot fix, and
the channel's own bounded backoff ladder already tried. Today that case instead loops
at the 10-restarts-per-hour cap forever, so this removes a restart treadmill rather
than adding one.
* fix(channels): keep automatic recovery for a dead-ingress account
The health-monitor skip latched a transient queue-open failure into a permanent
inbound outage: ingressUnavailable is only cleared by a later start, and skipping
the restart meant that start never happened. Report the dimension and name the
restart reason instead of suppressing recovery.
* fix(channels): scope the ingress dimension to running accounts
Shadowing not-running would have made readiness flap during the supervisor's
documented restart-backoff grace. The blind spot the dimension exists for is a
running channel with a live transport and dead inbound, so evaluate it there and
leave stopped accounts on their lifecycle reason. Also applies oxfmt.
* fix(channels): keep the ingress reason and give readiness its own backoff grace
Two review cycles pulled in opposite directions on the same bounded window: the
health policy must keep the ingress cause in the not-running state a failed start
actually lands in, while readiness must not flap during restart backoff. Put each
in its owner -- the policy states the truth, and readiness extends its existing
restart-handoff grace to the ingress reason. Once the ladder stops setting
restartPending, the account stays red instead of hiding dead inbound.
* style: reshape the readiness backoff predicate for oxfmt
* fix(ci): regenerate the docs map and drop an unused ingress export
The new health.md section needs docs/docs_map.md regenerated, and knip flagged
CHANNEL_INGRESS_UNAVAILABLE_CODE as an unused production export -- it only has
callers inside its own module.
Aggregators republish first-party models under a namespaced id and varying
case, so the shared-model check could not group novita/moonshotai/kimi-k3 with
moonshot/kimi-k3. Matching now ignores one leading namespace segment and case,
which catches that whole class automatically instead of needing an
upstreamModel marker per row.
Declares the tier on the 18 rows this surfaces across baseten, deepinfra, gmi,
novita, nvidia, and together. All are "capable", matching what the runtime
already applied for an absent flag, so behavior is unchanged.
* refactor(agents): share one tool-surface resolver across runner and harness
The code-mode vs tool-search gate decision and the three-way catalog
application were duplicated across the embedded runner and the native
harness bridge, and had already drifted: the harness copy was missing the
skillWorkshopProposalOnly condition and its params object had no field to
express it.
Both surfaces now consume resolveAgentToolSurfacePlan and
applyAgentToolSurfaceCatalog, so the gates and the catalog branch exist
once. Both gate booleans derive from a single shared toolsAvailable
intermediate.
Behavior change: the harness path now honors skillWorkshopProposalOnly.
Proposal-only skill-workshop runs are deliberately narrow single-tool runs,
so code-mode indirection and tool-search catalogs are pure overhead — a
harness-independent reason. Both callers currently pin
agentHarnessRuntimeOverride "openclaw", so this closes a latent fail-open
rather than fixing a live bug.
* fix(agents): let the shared catalog params carry a config-less run
resolveAgentToolSearchRuntimeConfig returns OpenClawConfig | undefined, so
requiring a non-null toolSearchRuntimeConfig broke tsgo:core at both call
sites. Keep the key required so it cannot be silently omitted, but let the
value be undefined as the pre-refactor code already allowed.
* fix(agents): keep the tool-surface module free of dead exports
Importing isCodeModeEngagedForModel and applyToolSchemaDirectoryCatalog from
their defining modules left the code-mode.ts and tool-search.ts re-exports with
no production consumer, which knip rejects. Go back through the barrels, which
is also what both call sites did before this refactor.
The two params types were exported only for the test, so knip's production scan
saw them as dead. Keep them module-local and derive the type in the test.
* feat(plugins): catch code-mode drift between catalogs sharing one model
Adds a contract test that groups bundled catalog rows by shared upstream
model and requires every row in a group to declare compat.codeMode once any
sibling does. Rows sharing a model id group automatically; rows under
different ids opt in with the new manifest-only `upstreamModel` marker.
Moves the kimi catalog into its manifest so the scan can see it, and records
the tier reseller catalogs were silently missing as explicit "capable".
* docs: regenerate docs map for the shared-model code-mode section
navigate and act results that changed the page document now include the
loaded page's compact snapshot inline (honoring browser.snapshotDefaults
and standard caps/wrapping), removing the follow-up snapshot round-trip.
Snapshot execution moves to browser-tool.snapshot.ts to keep action
executors under the file size cap.
The moonshot provider already declares compat.codeMode: "preferred" for the
same model (kimi-k3), so tools.codeMode: "auto" engaged code mode on the API
surface but silently skipped the Kimi Code subscription surface (kimi/k3,
kimi/k3-256k). Live proof on kimi/k3: "auto" reported codeModeEngaged=false
while true reported codeModeEngaged=true with "code-mode: cataloged 50 tools
behind exec/wait" and 2 bridge tool calls.
K2.7 (kimi-for-coding*) stays unflagged, matching moonshot's kimi-k2.7-code.
* feat(memory): add provenance and recall metadata to the memory index
* feat(memory): provenance-gated promotion and capture hygiene
* feat(dreaming): LLM consolidation with deterministic gates, on by default
* feat(active-memory): deterministic recall lane with escalation default
* feat(memory): user model file and standing intents
* docs(memory): document the memory architecture
* fix(memory): live-QA fixes — metadata writers, provenance classes, intent scope, claim accumulation
Restore the already shipped global exec approval notice setting through the same strict validator as its per-agent override.
Reported-by: @glorifiedautocomplete
Original-fix-by: @natedemoss (#57293)
An untrusted channel plugin cannot open its durable ingress queue, but the shared
ingress monitor resolved the queue lazily, so start() armed the poll timer anyway and
every tick re-invoked the throwing factory. On a production gateway that produced one
INFO-level "slack ingress drain failed" line per second for 26+ hours while Slack
reported connected and healthy and every inbound event was silently dropped.
Open the queue before arming the poll timer so an unusable monitor fails channel start
through the caller instead of spinning. Also report the actual denied capability:
openChannelIngressQueue and openSyncKeyedStore both announced themselves as
openKeyedStore, and the message named neither the plugin nor its origin.
The health monitor treated an account sleeping between its own auto-restart
attempts as "stopped" and force-restarted it. That start booted nothing (the
channel supervisor still owned the account task), but the accompanying
resetRestartAttempts wiped the retry ladder, so a crash-looping channel
restarted at attempt 1 every cooldown and could never reach
"giving up after 10 restart attempts".
ChannelManager now reports isAutoRestartScheduled for the supervisor's backoff
sleep and replacement start, and the health monitor defers to it instead of
restarting, resetting attempts, or spending its cooldown/hourly budget. The
monitor stays the last restart owner once the supervisor gives up.
Live evidence (clawmac gateway logs, 2026-07-27/28): 198 "restarting
(reason: stopped)" lines, zero give-ups, attempt ladders truncated at 8/10.
Related: #110802, #111572
* feat(config): give shared channel settings help text
* fix(ui): space the settings tiers and stop repeating help on list items
* feat(ui): link each channel detail to its docs page
* test(ui): mirror production channel hints in the mock dev server
* docs: note the shared channel help inheritance for plugin authors
* fix(config): let a channel suppress shared help with an empty string
* chore(config): regenerate bundled channel metadata for the new WhatsApp hints
* fix(ci): check bundled channel metadata locally
* chore(release): keep changelog release-owned
* chore(release): keep changelog release-owned
* fix(ui): keep shared channel help contract-neutral
clawSean