Bug Report: media-understanding audio transcription fails with "Command failed"

Summary

When receiving voice messages (audio/ogg) via Telegram, OpenClaw's media-understanding module attempts automatic transcription but consistently fails with reason=Command failed. The CLI command itself works fine when executed manually, suggesting the issue is in how OpenClaw invokes or passes arguments to the configured transcription command.

Environment

• OpenClaw Version: 2026.4.24 (cbcfdf6)
• OS: macOS (Darwin 25.3.0, arm64)
• Channel: Telegram
• Python: /opt/homebrew/bin/python3 (Homebrew)
• Transcription Tool: mlx_whisper via custom CLI script

Configuration

~/.openclaw/openclaw.json:

{
  "audio": {
    "enabled": true,
    "timeoutSeconds": 60,
    "language": "zh",
    "models": [
      {
        "type": "cli",
        "command": "/Users/kk/.local/bin/transcribe",
        "args": ["{input}"]
      }
    ],
    "echoTranscript": true,
    "echoFormat": "🎙️ \"{transcript}\""
  }
}

Custom transcribe script (/Users/kk/.local/bin/transcribe):

#!/bin/bash
/opt/homebrew/bin/python3 -c "
import sys, mlx_whisper
result = mlx_whisper.transcribe(sys.argv[1], path_or_hf_repo='mlx-community/whisper-tiny')
print(result['text'].strip())
" "$1"

Steps to Reproduce

1. Configure a CLI-based audio transcription model in OpenClaw
2. Send a voice message via Telegram
3. Observe that transcription fails

Expected Behavior

Voice message should be automatically transcribed and the text appended to the message context.

Actual Behavior

Gateway log shows:

[media-understanding] audio: failed (0/1) reason=Command failed

The transcription script works perfectly when executed manually with the exact same OGG file:

/Users/kk/.local/bin/transcribe /path/to/file.ogg
# => outputs transcribed text successfully

Additional Context

• This failure has been occurring consistently since at least 2026-04-19
• Manual execution of the same CLI command with the same input file works
• No additional error details (stderr/exit code) are logged by OpenClaw
• The {input} placeholder should resolve to the full path of the downloaded audio file

Root Cause Identified

The {input} placeholder is NOT being substituted with the actual file path.

When OpenClaw invokes the configured CLI command, it passes the literal string {input} as $1 instead of the downloaded audio file path.

Debug log from the transcription script:

Error opening input file {input}.
Error opening input files: No such file or directory

This confirms that sys.argv[1] received the string "{input}" rather than the actual file path.

Suspected Cause

OpenClaw's CLI invocation logic for audio transcription is not performing placeholder substitution for {input} before spawning the subprocess.

Feature Request: Better Error Reporting

It would be helpful if OpenClaw logged:

• The exact command being executed (after placeholder substitution)
• The exit code of the failed command
• stderr output from the failed command
• The working directory when the command was executed

Reported by: @kris-fan (via OpenClaw agent)