fix(microsoft-tts): default to Opus output format for voice message compatibility by w-sss · Pull Request #59652 · openclaw/openclaw

w-sss · 2026-04-02T11:53:08Z

Problem

TTS audio from Microsoft provider is delivered as MP3 file attachment instead of clickable voice message in Feishu (and likely Telegram/WhatsApp/Matrix). Users must download the file and play it manually.

Root Cause

The default Edge TTS output format is audio-24khz-48kbitrate-mono-mp3, which produces .mp3 files. The Feishu channel's media classification (resolveFeishuOutboundMediaKind) only treats .opus and .ogg as audio voice messages; MP3 files are sent as generic file attachments.

Additionally, isVoiceCompatibleAudio() in src/media/audio.ts checks for Telegram voice formats (ogg, opus, m4a) but not mp3.

Fix

Change DEFAULT_EDGE_OUTPUT_FORMAT from audio-24khz-48kbitrate-mono-mp3 to audio-24khz-48kbitrate-mono-opus. This ensures TTS audio is sent as Opus format, which is compatible with voice message features on all channels in OPUS_CHANNELS (Telegram, Feishu, WhatsApp, Matrix).

Test Plan

Microsoft TTS tests pass (11/11)
Manual testing: enable Microsoft TTS with Feishu, verify audio is sent as voice message (clickable bubble) not file attachment

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 255b4d8611

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

src/agents/tools/sessions-send-tool.ts

greptile-apps · 2026-04-02T11:55:30Z

Greptile Summary

Note: the PR title and description reference Microsoft TTS / Opus audio format, but the actual diff modifies sessions-send-tool.ts (cross-agent messaging policy) and exec-approvals.ts (allowlist-entry persistence). No TTS-related file is changed.

The exec-approvals persistence changes are correct: they preserve the loaded defaults object through multiple normalizeExecApprovals round-trips so that allow-always entries are not silently dropped. The new test file covers the key scenarios well.

The sessions-send-tool.ts change contains a P1 variable-shadowing bug: the inner const isCrossAgent never updates the outer let isCrossAgent, so resolveSessionReference and resolveVisibleSessionReference still receive the original restrictToSpawned flag for cross-agent sends, blocking them in sandboxed mode despite a passing a2aPolicy check.

Confidence Score: 4/5

Not safe to merge until the variable-shadowing bug in sessions-send-tool.ts is fixed; exec-approvals changes are correct.
One P1 logic bug: const isCrossAgent shadows let isCrossAgent, leaving the downstream resolveSessionReference / resolveVisibleSessionReference calls with restrictToSpawned unchanged for cross-agent sends. This directly breaks the main behavioural intent of the sessions-send change. The exec-approvals and test changes are sound and don't warrant a lower score.
src/agents/tools/sessions-send-tool.ts — variable shadowing on line 136

Prompt To Fix All With AI

This is a comment left during a code review.
Path: src/agents/tools/sessions-send-tool.ts
Line: 136-138

Comment:
**`isCrossAgent` inner `const` shadows outer `let`, leaving downstream calls broken**

`const isCrossAgent` declared on line 136 creates a new binding inside the `if (!sessionKey && labelParam)` block, shadowing the outer `let isCrossAgent = false` on line 128. The inner value is never written back, so when `resolveSessionReference` (line 221) and `resolveVisibleSessionReference` (line 233) are called with `restrictToSpawned: restrictToSpawned && !isCrossAgent`, they read the outer variable, which is always `false`. This means `restrictToSpawned` is passed unchanged even for cross-agent sends, causing the visibility check to still block them in sandboxed mode — exactly the behaviour this PR was meant to fix.

```suggestion
        isCrossAgent = Boolean(
          requesterAgentId && requestedAgentId && requestedAgentId !== requesterAgentId,
        );
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix(sessions_send): pass restrictToSpawn..." | Re-trigger Greptile}

src/agents/tools/sessions-send-tool.ts

aisle-research-bot · 2026-04-02T12:07:07Z

🤖 We're reviewing this PR with Aisle

We're running a security check on the changes in this PR now. This usually takes a few minutes. ⌛
We'll post the results here as soon as they're ready.

Progress:

Analysis
Finalization

Latest run failed. Keeping previous successful results. Trace ID: 019d4e0a51a0e6230d6fbae9184b7207.

_{Last updated on: 2026-04-02T13:25:54Z}

…w#58662) - Fix loadExecApprovals() to preserve parsed.defaults before normalization - Fix ensureExecApprovals() to preserve loaded defaults field - Fix resolveExecApprovalsFromFile() to preserve original defaults - Add regression tests for allow-always persistence - Address Greptile P2 feedback (simplify hasDefaults, document env var) Fixes openclaw#58662

…with a2a enabled - Move a2aPolicy check before restrictToSpawned guard so sandboxed agents can send messages to other agents when tools.agentToAgent is configured - Don't apply spawnedBy filter for cross-agent a2a messaging, allowing target agent's sessions to be visible during lookup - Fixes openclaw#59256

…esolve calls - Move isCrossAgent declaration outside label block so it's visible to resolveSessionReference and resolveVisibleSessionReference - Use Boolean() wrapper for explicit boolean type (fixes Greptile P2) - Pass restrictToSpawned && !isCrossAgent to both resolveSessionReference and resolveVisibleSessionReference so cross-agent a2a sends bypass spawned-session checks (fixes Greptile P1) - Add runtime guard for requesterAgentId/requestedAgentId in a2aPolicy.isAllowed call Fixes Greptile P1/P2 review comments on PR openclaw#59477

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: edd703be10

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

chatgpt-codex-connector · 2026-04-03T00:24:13Z

src/infra/exec-approvals.ts

+  // when normalizeExecApprovals drops undefined fields.
+  // Note: params.file.defaults takes precedence because normalizeExecApprovals
+  // always produces a defaults object (with undefined values for unset fields).
+  const defaults = params.file.defaults ?? file.defaults ?? {};


Resolve exec policy from normalized defaults

Using params.file.defaults here bypasses normalizeExecApprovals() sanitization. If a persisted config contains whitespace-padded values like "security": "allowlist " or "ask": "on-miss ", loadExecApprovals()/ensureExecApprovals() now keep that raw object and this resolver falls back to permissive defaults (security: "full", ask: "off") instead of honoring the configured policy. This is a regression from the previous normalized-only path and can silently disable approval gating for manually edited configs.

Useful? React with 👍 / 👎.

chatgpt-codex-connector · 2026-04-03T00:24:13Z

src/infra/exec-approvals.ts

+  if (process.env.OPENCLAW_EXEC_APPROVALS_FILE) {
+    return process.env.OPENCLAW_EXEC_APPROVALS_FILE;
+  }


Expand override approvals path before use

Returning OPENCLAW_EXEC_APPROVALS_FILE verbatim means common values like ~/.openclaw/exec-approvals.json are treated as literal relative paths, so reads/writes can go to an unintended ~/... folder under the process working directory. Since every approval load/save path now depends on this helper, operators using ~ in the new override can silently read/write the wrong policy file.

Useful? React with 👍 / 👎.

BradGroux · 2026-04-03T03:49:03Z

Hey @w-sss — thanks for the contribution! However, the diff on this PR doesn't match the title or description.

Title: fix(microsoft-tts): default to Opus output format for voice message compatibility

Actual changes in the diff:

src/agents/tools/sessions-send-tool.ts — cross-agent session messaging changes
src/infra/exec-approvals.ts — exec approvals persistence fixes
src/infra/exec-approvals-persist.test.ts — new test for exec approvals

There are zero lines of TTS, audio, Opus, or Microsoft speech code touched. This looks like the intended commits may have been lost during a rebase, or the wrong branch was pushed.

Closing this one — feel free to open a fresh PR with the correct TTS changes if you'd like to try again. 👍

openclaw-barnacle bot added agents Agent runtime and tooling size: M labels Apr 2, 2026

chatgpt-codex-connector bot reviewed Apr 2, 2026

View reviewed changes

src/agents/tools/sessions-send-tool.ts Show resolved Hide resolved

greptile-apps bot reviewed Apr 2, 2026

View reviewed changes

src/agents/tools/sessions-send-tool.ts Show resolved Hide resolved

BradGroux mentioned this pull request Apr 2, 2026

WORKING: All Microsoft Issues and PRs #49126

Draft

w-sss added 3 commits April 3, 2026 08:18

w-sss force-pushed the fix/59588-feishu-tts-opus-format branch from 255b4d8 to edd703b Compare April 3, 2026 00:18

chatgpt-codex-connector bot reviewed Apr 3, 2026

View reviewed changes

BradGroux closed this Apr 3, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(microsoft-tts): default to Opus output format for voice message compatibility#59652

fix(microsoft-tts): default to Opus output format for voice message compatibility#59652
w-sss wants to merge 3 commits intoopenclaw:mainfrom
w-sss:fix/59588-feishu-tts-opus-format

w-sss commented Apr 2, 2026

Uh oh!

chatgpt-codex-connector bot left a comment

Uh oh!

Uh oh!

greptile-apps bot commented Apr 2, 2026

Uh oh!

Uh oh!

aisle-research-bot bot commented Apr 2, 2026 •

edited

Loading

Uh oh!

chatgpt-codex-connector bot left a comment

Uh oh!

chatgpt-codex-connector bot Apr 3, 2026

Uh oh!

chatgpt-codex-connector bot Apr 3, 2026

Uh oh!

BradGroux commented Apr 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

w-sss commented Apr 2, 2026

Problem

Root Cause

Fix

Test Plan

Uh oh!

chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

greptile-apps bot commented Apr 2, 2026

Greptile Summary

Confidence Score: 4/5

Uh oh!

Uh oh!

aisle-research-bot bot commented Apr 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector bot Apr 3, 2026

Choose a reason for hiding this comment

Uh oh!

chatgpt-codex-connector bot Apr 3, 2026

Choose a reason for hiding this comment

Uh oh!

BradGroux commented Apr 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

aisle-research-bot bot commented Apr 2, 2026 •

edited

Loading