Feature Request: Add Edge TTS support

[dongkun666]

Summary

I'd like to request adding Edge TTS as a new TTS provider in OpenClaw.

Current State

Currently, OpenClaw only supports three TTS providers:

1. Piper
2. Windows (built-in)
3. ElevenLabs

Feature Request

I would love to see Edge TTS (Microsoft Azure's free speech synthesis API) added as a fourth provider.

Benefits

• No API Key required — completely free to use
• High quality natural voices, including popular Chinese voices such as:
  • Xiaoxiao (晓晓)
  • Yunyang (云扬)
  • Yunxi (云希)
• Easy integration — Edge TTS is widely used in the open-source community with mature libraries available (e.g., edge-tts for Python)
• No additional cost for users who want high-quality TTS without subscribing to paid services like ElevenLabs

Proposed Implementation

Add an edge TTS provider option alongside the existing piper, windows, and elevenlabs providers. The implementation could leverage existing open-source Edge TTS libraries to handle the WebSocket-based communication with Microsoft's speech service.

Use Case

This would be especially valuable for users who need natural-sounding Chinese text-to-speech without incurring costs, bridging the gap between the basic Windows built-in voices and the premium ElevenLabs voices.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 17, 2026, 4:46 AM ET / 08:46 UTC.

Summary
Keep open: current main has an extensible voice-provider catalog but no Edge TTS provider, so the requested capability remains missing. Adding another network speech backend requires maintainer direction on whether Windows Voice Mode should own a second Microsoft implementation or reuse OpenClaw's existing gateway-level Microsoft TTS path.

Likely related people: RBrid is the strongest feature-history owner; NichUK and shanselman are also connected through the original voice-mode and TTS capability work.

Reproducibility: not applicable. This issue requests a new provider rather than reporting broken established behavior; current-main inspection confirms the provider is absent.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
A feature owner should first decide gateway reuse versus node-local provider ownership and approve the external-service policy before implementation begins.

Maintainer decision needed

• Question: Should Windows Voice Mode reuse OpenClaw's existing gateway-level Microsoft TTS provider, or own a separate node-local Edge TTS integration?
• Rationale: Both approaches can provide the requested voices, but they establish different long-term provider contracts, privacy disclosures, dependency boundaries, and failure behavior; repository history does not establish which layer should own this duplication.
• Likely owner: RBrid — RBrid introduced the shared TTS capability contract and has the strongest history connection to deciding where another provider belongs.
• Options:
  • Reuse Gateway Provider (recommended): Route compatible Voice Mode synthesis through OpenClaw's existing Microsoft TTS provider and avoid maintaining a second Edge protocol implementation.
  • Add Node Provider: Approve a node-local catalog provider when offline-independent Windows playback is required, with explicit egress disclosure and end-to-end proof.
  • Decline Bundling: Keep the current provider set and leave unsupported Edge integration outside the bundled Windows node.

Review details

Best possible solution:

Choose one Microsoft TTS ownership path: preferably reuse the gateway's existing provider when Voice Mode can consume it, or otherwise add a catalog-backed node provider with explicit data-egress disclosure, configurable voices, graceful failure behavior, MCP documentation, focused tests, and current-head Windows playback proof.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this issue requests a new provider rather than reporting broken established behavior; current-main inspection confirms the provider is absent.

Is this the best way to solve the issue?

Unclear: adding a standalone Edge adapter is feasible, but reusing the existing gateway-level Microsoft provider would be narrower and avoid competing implementations if the architecture supports it.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A node-local Edge implementation may duplicate OpenClaw's existing gateway-level Microsoft TTS support and create two provider contracts with different voice names, behavior, and maintenance paths.
• Edge synthesis sends spoken text to an external Microsoft service, so the product must disclose network egress and establish acceptable service reliability and usage-policy expectations.
• The existing generic cloud transport may not directly model Edge's WebSocket framing and SSML protocol, making the actual implementation boundary larger than a catalog-only addition.

Codex review notes: model internal, reasoning high; reviewed against 9fb1960ec434.

Label changes

Label changes:

• add P3: This is a speculative optional provider addition rather than a regression or blocked core workflow.
• add issue-rating: 🌊 off-meta tidepool: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P3: This is a speculative optional provider addition rather than a regression or blocked core workflow.

Evidence reviewed

What I checked:

• Provider remains absent: The current-main voice provider catalog contains the built-in provider configuration surface but no Edge or Microsoft Edge TTS entry, so the requested provider is not implemented. (src/OpenClaw.Tray.WinUI/Assets/voice-providers.json, 9fb1960ec434)
• Current user-facing contract: Current-main documentation describes Windows and ElevenLabs speech support without documenting Edge TTS as an available provider. (README.md:508, 9fb1960ec434)
• Provider architecture: Voice-mode documentation describes catalog-driven cloud transports and provider-specific request details, indicating Edge support would need a deliberate transport/configuration implementation rather than only a label change. (docs/VOICE-MODE.md, 9fb1960ec434)
• Feature provenance: Merged pull request Add Windows node text-to-speech #253 introduced the shared text-to-speech node capability in commit 7ae8677, authored by RBrid, merged by shanselman, and crediting prior voice-mode work by NichUK. (src/OpenClaw.Tray.WinUI/App.CapabilityHandlers.cs, 7ae8677)
• Related-PR check: The context-associated Redesign WSL gateway setup and OpenClaw onboard UX #925 concerns WSL setup and onboarding and explicitly leaves node/MCP command contracts unchanged; it does not implement this provider request. (9fb1960ec434)
• Release check: The latest release, v0.6.12, predates this request, and current main still lacks an Edge provider entry; there is therefore no released or main-only implementation to close against. (src/OpenClaw.Tray.WinUI/Assets/voice-providers.json, 4166e0fd63f8)

Likely related people:

• RBrid: Authored the merged change that introduced the repository's shared text-to-speech capability and is the strongest history signal for the affected contract. (role: introduced behavior; confidence: high; commits: 7ae8677; files: src/OpenClaw.Tray.WinUI/App.CapabilityHandlers.cs, src/OpenClaw.Shared/Capabilities/CapabilityDefinitions.cs, README.md)
• NichUK: Prior voice-mode work was explicitly credited by the merged TTS capability PR, connecting this contributor to the provider and playback architecture. (role: feature contributor; confidence: medium; files: src/OpenClaw.Tray.WinUI/Services/VoiceService.cs, src/OpenClaw.Tray.WinUI/Assets/voice-providers.json, docs/VOICE-MODE.md)
• shanselman: Merged the TTS capability change and is therefore a useful routing candidate for the original capability boundary and review intent. (role: merger; confidence: medium; commits: 7ae8677; files: src/OpenClaw.Tray.WinUI/App.CapabilityHandlers.cs, src/OpenClaw.Shared/Capabilities/CapabilityDefinitions.cs)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.