TTS tool audio blocked by normalizeReplyMediaPaths when sandbox mode is "off"

Description

The built-in tts tool generates audio files at /tmp/openclaw/tts-*/voice-*.mp3. When sandbox mode is "off" (default), these files are silently dropped by normalizeReplyMediaPaths because isAllowedAbsoluteReplyMediaPath does not permit /tmp/openclaw/ paths in the non-sandboxed code path.

This is a regression introduced in v2026.3.22 (commit 3cd4978fc2 — "refactor(agents): unify tool media reply delivery"). TTS tool audio delivery works on v2026.3.7 but breaks on v2026.3.22+.

Regression timeline

• v2026.3.7 and earlier: Tool results used inline MEDIA: directives, bypassing normalizeReplyMediaPaths. TTS worked.
• v2026.3.22: Commit 3cd4978fc2 unified tool media delivery to use structured details.media.mediaUrl, which now routes through createReplyMediaPathNormalizer(). /tmp/openclaw/ paths hit isAllowedAbsoluteReplyMediaPath for the first time and get blocked.
• v2026.3.24: Further tightened in commit c92002e1 ("fix(media): align outbound media access with fs policy").
• v2026.4.7: Partial fix re-allowed managed MEDIA: paths but did NOT add /tmp/openclaw/ to the allowlist.
• v2026.4.9: Still broken.

Related PRs

• PR #63511: "fix(tts): allow OpenClaw temp directory paths in reply media normalizer"
• PR #63932: "fix: allow TTS tool media delivery to channels"

Steps to reproduce

1. Set sandbox.mode: "off" (default)
2. Do NOT configure messages.tts (leave empty — TTS tool is always available)
3. Send a message like "Say hello as a voice message"
4. Agent calls the tts tool, generates /tmp/openclaw/tts-*/voice-*.mp3
5. Audio file is created but never delivered to the channel

Expected behavior

The TTS audio should be delivered to the channel via emitBlockReply → blockReplyHandler → channel's deliver callback, regardless of sandbox mode.

Actual behavior

normalizeReplyMediaPaths in agent-runner.runtime calls isAllowedAbsoluteReplyMediaPath, which:

1. Checks isManagedGlobalReplyMediaPath → false (/tmp/openclaw/ is not under ~/.openclaw/media/)
2. Checks workspace/sandbox roots → false (sandbox is off, no sandboxRoot)
3. Throws "Absolute host-local MEDIA paths are blocked in normal replies."
4. Catch handler silently drops the media: logVerbose("dropping blocked reply media...")
5. Payload arrives at the channel with mediaUrl: undefined — audio lost

Root cause

In isAllowedAbsoluteReplyMediaPath, the function resolveAllowedTmpMediaPath (which correctly allows /tmp/openclaw/*) is only called inside the if (sandboxRoot) branch. When sandbox mode is "off", sandboxRoot is undefined and this check is never reached.

Since /tmp/openclaw/* files are always created by OpenClaw itself (via resolvePreferredOpenClawTmpDir() for TTS, image generation, etc.), they should be allowed regardless of sandbox mode.

Suggested fix

In isAllowedAbsoluteReplyMediaPath, add the /tmp/openclaw/ check before the sandbox-specific checks:

function isAllowedAbsoluteReplyMediaPath(params) {
    // OpenClaw's own temp files should always be allowed
    if (params.candidate.startsWith("/tmp/openclaw/")) return true;
    if (isManagedGlobalReplyMediaPath(params.candidate)) return true;
    // ... existing sandbox checks
}

Or more robustly, call resolveAllowedTmpMediaPath() regardless of sandbox mode.

Workaround

Patch agent-runner.runtime-*.js manually after each OpenClaw install:

sed -i 's/function isAllowedAbsoluteReplyMediaPath(params) {/function isAllowedAbsoluteReplyMediaPath(params) {\n\tif (params.candidate.startsWith("\/tmp\/openclaw\/")) return true;/' \
  /usr/lib/node_modules/openclaw/dist/agent-runner.runtime-*.js

Note: This patch is overwritten by every npm install -g openclaw@latest.

Environment

• OpenClaw v2026.4.9 (broken)
• OpenClaw v2026.3.7 (works)
• Regression introduced: v2026.3.22
• sandbox.mode: "off" (default)
• TTS provider: ElevenLabs and edge (both affected)
• Tested on custom channel plugin, but affects all channels