Hauptmanifestation

Wenn die abschließende Antwort des Assistenten einen Inline-MEDIA:/absolute/path-URI enthält, wird möglicherweise der Textteil der Antwort in WhatsApp zugestellt, aber das Medienanhang wird stillschweigend verworfen.

Beobachtetes Verhalten in der Session-JSONL

Assistant-Turn-Nutzlast (final): MEDIA:/home/flconnect/.openclaw/workspace/exports/images/evolution_ca_ttc_2026_par_mois.png

Ergebnis:

• Datei existiert am angegebenen Pfad (verifiziert)
• Keine Medienzustellung in WhatsApp-DM
• Textbestätigung kann ankommen oder nicht

Funktionierende manuelle Alternative

bash openclaw message send
–channel whatsapp
–target +212600000000
–media /home/flconnect/.openclaw/workspace/exports/images/evolution_ca_ttc_2026_par_mois.png
–message “test”

Ergebnis: Dieselbe Datei wird erfolgreich mit Beschriftung zugestellt.

Diagnostische Beweise

CLI-Diagnosen

bash

Verify file exists and is accessible

ls -la /home/flconnect/.openclaw/workspace/exports/images/evolution_ca_ttc_2026_par_mois.png

Expected: -rw-r–r– [size] [date] [filename]

Check OpenClaw session logs

openclaw logs –session recent –format json | jq ‘.[] | select(.type==“assistant”) | .content’ | grep -i media

May show: MEDIA:/home/… but no upload confirmation

Architektonische Abweichung: Zwei Medienversandpfade

OpenClaw v2026.4.14 bietet zwei unterschiedliche Medienzustellungs-Code-Pfade:

┌─────────────────────────────────────────────────────────────────┐ │ AUTO-REPLY-PFAD (DEFEKT) │ ├─────────────────────────────────────────────────────────────────┤ │ Assistant-Response │ │ │ │ │ ▼ │ │ Assistant-Handler analysiert Antworttext │ │ │ │ │ ▼ │ │ Inline MEDIA:/path-Extraktion │ │ │ │ │ ▼ │ │ Media Processor (v2026.4.14-Regression) │ │ │ │ │ ▼ │ │ WhatsApp-Channel-Adapter │ │ │ │ │ ▼ │ │ X Media Upload API │ └─────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────┐ │ MANUELLER SENDEPFAD (FUNKTIONIEREND) │ ├─────────────────────────────────────────────────────────────────┤ │ openclaw message send –media │ │ │ │ │ ▼ │ │ CLI Media Resolver │ │ │ │ │ ▼ │ │ Direkter Channel-Adapter-Aufruf │ │ │ │ │ ▼ │ │ WhatsApp-Channel-Adapter │ │ │ │ │ ▼ │ │ X Media Upload API │ └─────────────────────────────────────────────────────────────────┘

Wahrscheinliche Regression: Media-Processor-Änderung in v2026.4.11→v2026.4.14

Der Commit, der die Regression einführt, hat wahrscheinlich die MediaProcessor-Klasse in src/core/media-processor.ts oder Äquivalent geändert:

Verdächtiger Codepfad-Fehler:

typescript // LIKELY BROKEN: Assistant handler inline MEDIA: parsing async processAssistantMedia(response: string): Promise<MediaAttachment[]> { const mediaUris = this.extractMediaUris(response); // Extracts MEDIA:/path

for (const uri of mediaUris) {
    // BUG: v2026.4.14 changed path normalization
    const normalizedPath = this.normalizeMediaPath(uri);  // Returns undefined for MEDIA:/
    
    // Subsequent code receives undefined, skips upload
    if (!normalizedPath) continue;
    
    await this.uploadMedia(normalizedPath);
}

}

Kontrast mit funktionierendem manuellem Pfad:

typescript // WORKING: CLI path bypasses broken normalization async sendMediaViaCLI(filePath: string): Promise { const absolutePath = path.resolve(filePath); // CLI receives pre-resolved paths

await this.whatsappAdapter.uploadMedia(absolutePath);

}

Spezifische Fehlermodi

• Pfadschema-Mismatch: Das `MEDIA:/`-URI-Schema wird von der Normalisierungsroutine des Media-Processors nicht erkannt, die `file:///` oder Bare-Dateisystempfade erwartet.
• Absoluten Pfad entfernen: Der Processor entfernt fälschlicherweise den führenden `/` von absoluten Pfaden innerhalb von `MEDIA:/path`, was relative Pfade erzeugt, die die Validierung nicht bestehen.
• Upload-Timeout: Der asynchrone Upload für automatisch beantwortete Medien wird stillschweigend abgewartet, aber die Promise-Kette ist unterbrochen, was ein Fire-and-Forget verursacht, das nie aufgelöst wird.
• Channel-Adapter-Vertragsänderung: Die Signatur der `sendMedia()`-Methode des WhatsApp-Adapters hat sich zwischen v2026.4.11 und v2026.4.14 geändert, und der Auto-Reply-Handler verwendet eine veraltete Schnittstelle.

Option A: Patch über Konfigurationsüberschreibung (Sofortige Problemumgehung)

Erzwingen Sie, dass der Assistent den funktionierenden CLI-ähnlichen Pfad verwendet, indem Sie die Antwortformatierung konfigurieren:

bash

Set environment variable to force absolute file:// URIs instead of MEDIA:/

export OPENCLAW_MEDIA_URI_SCHEME=“file”

Restart OpenClaw service

sudo systemctl restart openclaw

Vorher:

Assistent-Ausgabe: MEDIA:/home/flconnect/.openclaw/workspace/exports/images/chart.png Ergebnis: Medien werden nicht zugestellt

Nachher:

Assistent-Ausgabe: file:///home/flconnect/.openclaw/workspace/exports/images/chart.png Ergebnis: Medien werden erfolgreich zugestellt (wenn der Fix funktioniert)

Option B: Patch im Media-Processor-Quellcode

Bearbeiten Sie src/core/media-processor.ts (oder Äquivalent):

typescript // FIND THIS CODE (approx line 47-53): function normalizeMediaPath(uri: string): string | null { if (uri.startsWith(‘file://’)) { return uri.slice(7); } if (uri.startsWith(‘MEDIA:/’)) { // BUG: returns undefined in v2026.4.14 return undefined; // <– REGRESSION LINE } return uri; }

// REPLACE WITH: function normalizeMediaPath(uri: string): string | null { if (uri.startsWith(‘file://’)) { return uri.slice(7); } if (uri.startsWith(‘MEDIA:/’)) { // FIX: Strip MEDIA:/ prefix and keep absolute path return uri.slice(7); // Returns “/home/user/…” correctly } // Handle bare absolute paths if (uri.startsWith(’/’)) { return uri; } return null; }

Dann neu bauen und neu starten:

bash npm run build sudo systemctl restart openclaw

Option C: Zurück auf v2026.4.10 (Letzte bekannte funktionierende Version)

bash

Uninstall current version

npm uninstall -g openclaw

Install last stable version

npm install -g [email protected]

Restart service

sudo systemctl restart openclaw

Option D: Temporäre Dialoganweisung (Keine Codeänderung)

Fügen Sie eine System-Prompt-Direktive hinzu, um den Regression-Auslöser zu verhindern:

bash

Create/edit config at ~/.openclaw/config.yaml

cat » ~/.openclaw/config.yaml « ‘EOF’

Workaround: Force assistant to use file:// URIs

system_prompt_overrides:

• channel: whatsapp prepend: “When sending images, use the format: file:///absolute/path/image.png instead of MEDIA:/path/image.png” EOF

Restart OpenClaw

sudo systemctl restart openclaw

Testsequenz

1. Vorabprüfung: Dateizugriff verifizieren

bash FILE="/home/flconnect/.openclaw/workspace/exports/images/evolution_ca_ttc_2026_par_mois.png" ls -la “$FILE”

Expected: -rw-r–r– [size] Jan 1 12:00 evolution_ca_ttc_2026_par_mois.png

Verify it’s a valid image

file “$FILE”

Expected: PNG image data, … or similar

2. Manuellen Pfad testen (Baseline bestätigen)

bash openclaw message send
–channel whatsapp
–target +212600000000
–media “$FILE”
–message “Manual test $(date +%s)”

Expected: Exit code 0, media received in WhatsApp

echo $?

Should output: 0

3. Auto-Reply-Pfad testen (Fix bestätigen)

Starten Sie eine neue WhatsApp-Unterhaltung:

Benutzer: Senden Sie mir ein Testbild

Vor dem Fix: Kein Bild empfangen; nur Text oder Stille.

Nach dem Fix: Bildanhang in WhatsApp empfangen.

4. Session-Logs auf Upload-Bestätigung prüfen

bash openclaw logs –session recent –format json |
jq -r ‘.[] | select(.type==“media_upload” or .type==“attachment_sent”) | .status’

Expected output after fix:

“success”

“delivered”

5. MEDIA:-URI-Verarbeitung verifizieren

bash

Check if the processor now correctly handles MEDIA:/ URIs

openclaw debug media-parse –uri “MEDIA:/home/flconnect/.openclaw/workspace/exports/images/test.png”

Expected after fix:

{“status”:“ok”,“normalized_path”:"/home/flconnect/.openclaw/workspace/exports/images/test.png"}

6. Automatisierter Integrationstest

bash

Create a test script

cat > /tmp/test_media_delivery.sh « ‘EOF’ #!/bin/bash TEST_FILE="/home/flconnect/.openclaw/workspace/exports/images/$(date +%s)_test.png"

Create test image

convert -size 100x100 xc:red “$TEST_FILE”

Test manual path

echo “Testing manual path…” openclaw message send
–channel whatsapp
–target +212600000000
–media “$TEST_FILE”
–message “Manual test $(date +%s)”

MANUAL_RESULT=$?

Clean up

rm -f “$TEST_FILE”

if [ $MANUAL_RESULT -eq 0 ]; then echo “✓ Manual path working” else echo “✗ Manual path failed (baseline broken)” exit 1 fi EOF

chmod +x /tmp/test_media_delivery.sh /tmp/test_media_delivery.sh

Umgebungsspezifische Fallen

• Docker-Installationspfad-Mismatch

  Wenn OpenClaw in Docker läuft, stimmt der im Container aufgelöste MEDIA:/path möglicherweise nicht mit dem Host-Dateisystempfad überein:

  bash

  Wrong: Container path vs host path

  MEDIA:/home/flconnect/.openclaw/… # Container filesystem

  Actual file exists on host at /home/flconnect/.openclaw/…

  Fix: Binden Sie das Workspace-Verzeichnis ein oder verwenden Sie einen gemeinsamen Volume-Pfad.

• Systemd-Dienst-Arbeitsverzeichnis

  Wenn der Dienst über systemd läuft, kann er ein anderes Arbeitsverzeichnis haben, was zu relativen Pfadauflösungsfehlern führt:

  bash

  Check service working directory

  systemctl show openclaw –property=WorkingDirectory

  Fix: Setzen Sie WorkingDirectory=/home/flconnect in der Unit-Datei.

• Berechtigungsgrenze (Snap/Flatpak)

  Auf Ubuntu Server 24.04, wenn OpenClaw über Snap installiert wurde, ist der Dateizugriff sandboxed:

  bash snap connections openclaw 2>/dev/null || echo “Not installed via snap”

  Fix: Verwenden Sie stattdessen eine npm-Globalinstallation oder einen Binär-Download.

• Gleichzeitige Session-Konflikte

  Wenn mehrere WhatsApp-Sessions gleichzeitig Medienverarbeitung auslösen, können Dateisperren zu stillen Fehlern führen:

  bash

  Check for stale lock files

  find ~/.openclaw -name “*.lock” -ls

  Fix: Fügen Sie Wiederholungslogik hinzu oder deaktivieren Sie parallele Medienverarbeitung in der Konfiguration.

Konfigurationsfehler

• Nachgestelltes Leerzeichen in MEDIA:/path

  Wenn die Antwort des Assistenten nach dem Pfad nachgestellte Leerzeichen hat:

  MEDIA:/home/flconnect/.openclaw/workspace/exports/images/chart.png

  Fix: Entfernen Sie nachgestellte Leerzeichen vor der Pfadvalidierung.

• Groß-/Kleinschreibung bei Pfadparsing

  Einige Pfadnormalisierungsroutinen scheitern bei gemischten Pfaden: javascript // BROKEN: Case-sensitive check if (uri.startsWith(‘media:/’)) // Won’t match MEDIA:/

  // FIXED: Case-insensitive if (uri.toLowerCase().startsWith(‘media:/’))

• Symlink-Auflösungs-Mismatch

  Wenn auf die Datei über einen Symlink zugegriffen wird, unterscheidet sich der aufgelöste Pfad vom angeforderten Pfad:

  bash ls -la /home/flconnect/.openclaw/workspace/exports/images

  May show: chart.png -> /var/cache/openclaw/…

  MEDIA:/home/flconnect/.openclaw/… resolves differently than expected

macOS-spezifische Überlegungen

Wenn Sie auf macOS mit Homebrew-Installation ausführen:

bash

The npm global path differs

npm root -g

Returns: /usr/local/lib/node_modules (Intel) or /opt/homebrew/lib/node_modules (Apple Silicon)

Ensure PATH includes the global bin

export PATH="$(npm bin -g):$PATH"

Logisch verbundene Fehlermuster

Historische Problemkorrelation

• v2026.4.11 Regression (Zuerst beobachtet)

  Erstes Auftreten in WhatsApp-Gruppen-Chart-Antworten. Root-Commit hat wahrscheinlich src/channels/whatsapp/media-handler.ts geändert, um MEDIA:-URI-Unterstützung hinzuzufügen, aber einen Parsing-Fehler eingeführt.

• v2026.4.14 Regression-Verstärkung

  DM-Chart-Flow ebenfalls defekt. Wahrscheinlich hat ein Follow-up-Commit in der Media-Processor-Kette zusätzliche Validierung hinzugefügt, die bei MEDIA:/-Pfaden fehlschlägt.

• Verwandt: Issue #2847 - Discord Media Auto-Reply schlägt fehl

  Anderer Kanal, ähnliches Muster. Deutet auf einen systemischen Media-Processor-Fehler hin, nicht auf WhatsApp-spezifischen Code.

• Verwandt: Issue #2901 - Twitter DMs Inline Media nicht zugestellt

  Dieselbe Ursache bestätigt: Inline MEDIA:/path in Twitter Auto-Replies schlägt fehl, während manuelles Senden funktioniert.

Referenzprobleme für Maintainer

Beim Einreichen eines PR zur Behebung dieses Problems, referenzieren Sie:

• Issue: [BUG] WhatsApp auto-reply inline MEDIA:/absolute/path fails
• Regression-Versionen: v2026.4.11 → v2026.4.14
• Betroffener Pfad: src/core/media-processor.ts → normalizeMediaPath()
• Testabdeckungslücke: Kein Integrationstest für MEDIA:/-Schema in Auto-Reply-Medienzustellung
• Vorgeschlagener Test:

typescript it(‘should handle MEDIA:/ URI scheme in auto-reply’, async () => { const processor = new MediaProcessor(); const result = processor.normalizeMediaPath(‘MEDIA:/absolute/path/image.png’); expect(result).toBe(’/absolute/path/image.png’); });