Regression on FixClaw

Chrome Exits Immediately After OpenClaw Launch on Windows 11 - CDP Never Binds

Sun, 12 Apr 2026 00:00:00 +0000

Symptom

On Windows 11, when attempting to start a managed browser using OpenClaw, Chrome launches successfully with the correct CDP flags and a PID is returned, but Chrome terminates within seconds before CDP can bind to port 18800.

Observed behavior:

OpenClaw spawns Chrome and logs the PID: [browser/chrome] 🦞 openclaw browser started (custom) profile “openclaw” on 127.0.0.1:18800 (pid 9592)
Chrome process immediately exits
Connection attempts fail: [ws] ⇄ res ✗ browser.request 10462ms errorCode=UNAVAILABLE errorMessage=Error: Chrome CDP websocket for profile “openclaw” is not reachable after start.
Verification commands confirm Chrome is not running:
- Get-Process -Name chrome → no processes
- Test-NetConnection 127.0.0.1 -Port 18800 → TcpTestSucceeded: False
- curl http://127.0.0.1:18800/json/version → connection refused

Expected behavior:

Chrome remains running after launch
CDP websocket becomes available on port 18800
openclaw browser status shows running: true

Root Cause Analysis

The issue is specifically in OpenClaw’s process lifecycle management after spawn. This conclusion is supported by the following evidence:

Factor Tested	Result
Chrome executable	Works when launched manually
All Chrome arguments	Identical args work when run manually in PowerShell
User data directory	Valid and functional when used outside OpenClaw
Sandbox settings	`noSandbox: true` makes no difference
Port 18800 availability	Port is not blocked; works with manual launch
CDP configuration	Functions correctly when Chrome runs independently

Key finding: When the exact same Chrome executable with identical arguments is launched manually from PowerShell, Chrome:

Stays alive
Serves CDP on port 18800 (TcpTestSucceeded: True)
Returns HTTP 200 on curl http://127.0.0.1:18800/json/version

This definitively rules out Chrome, arguments, user-data-dir, sandbox configuration, and port issues. The problem originates from how OpenClaw manages the spawned Chrome process after launch, likely in one of these areas:

Process inheritance - OpenClaw may be holding file handles or stdin/stdout pipes that cause Chrome to terminate
Process group handling - Windows process group termination may be killing the child process
Parent process exit propagation - Exit signals may be incorrectly propagating to the child Chrome process
Environment variable handling - Missing or incorrect environment variables passed to Chrome

Solution

This is a regression in OpenClaw’s browser process spawning mechanism. Until a permanent fix is released, the following workarounds can be used:

Workaround 1: Use attachOnly Mode

Configure a separate browser profile that connects to an already-running Chrome instance:

{ “browser”: { “profiles”: { “manual”: { “attachOnly”: true, “cdpPort”: 18800 } } } }

Then launch Chrome manually with debugging enabled: & “C:\Program Files\Google\Chrome\Application\chrome.exe” –remote-debugging-port=18800 –user-data-dir=“C:\Users\Me.openclaw\browser\openclaw\user-data”

Finally, connect using OpenClaw: openclaw browser –browser-profile manual start

Workaround 2: Launch Chrome Before OpenClaw Operations

Start Chrome manually before performing any OpenClaw browser operations, then use the attachOnly approach described above.

Prevention

To prevent this issue from affecting your workflow:

Monitor browser status before running commands that require CDP: openclaw browser status
Implement health checks in automation scripts:

Wait for browser to be ready
until curl -s http://127.0.0.1:18800/json/version > /dev/null; do sleep 0.5 done
Keep detailed logs of browser launches to quickly identify when this regression affects your environment
Test browser launches after OpenClaw updates, as this is identified as a regression

Additional Information

Environment Details:

OpenClaw version: 2026.4.11 (769908e)
Operating System: Windows 11
Chrome version: 146.0.7680.178
Chrome path: C:\Program Files\Google\Chrome\Application\chrome.exe

Working Chrome Launch Arguments: “C:\Program Files\Google\Chrome\Application\chrome.exe” –remote-debugging-port=18800 –user-data-dir=C:\Users\Me.openclaw\browser\openclaw\user-data –no-first-run –no-default-browser-check –disable-sync –disable-background-networking –disable-component-update –disable-features=Translate,MediaRouter –disable-session-crashed-bubble –hide-crash-restore-bubble –password-store=basic –no-sandbox –disable-setuid-sandbox

Browser Control Service Status: The browser control service itself is healthy and listening correctly: [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)

Sources

GitHub Issue #65521

TTS Voice Note Delivery Regression in v2026.4.9

Fri, 10 Apr 2026 00:00:00 +0000

Symptom

After upgrading to OpenClaw v2026.4.9, TTS (text-to-speech) voice note delivery is completely broken:

Outbound TTS (Voice Notes from Assistant):

User sends a text message to the assistant via Telegram
Assistant calls tts tool with channel: "telegram"
Tool returns Generated audio reply
Expected: Voice note delivered to user
Actual: Only text response received; no voice note

Inbound STT (Voice Notes to Assistant):

User sends a voice note to the assistant via Telegram
Expected: Audio transcribed and processed
Actual: No transcription; pdf tool fails with “Expected PDF but got audio/ogg”, image tool fails with “Unsupported media type: audio”

Evidence from logs:

Gateway logs show no TTS-related events after the tts tool call
No sendVoice API calls are made to Telegram
Text messages continue to work correctly (proving Telegram connectivity is intact)

Historical logs show the last sendVoice attempts failing: telegram sendVoice failed: Network request for ‘sendVoice’ failed! telegram final reply failed: HttpError: Network request for ‘sendVoice’ failed!

Root Cause Analysis

The investigation reveals that the tool→channel delivery handoff is broken:

ElevenLabs API is functioning correctly — Audio files are successfully generated by the tts tool
Tool reports success — Generated audio reply message confirms audio creation
Broken handoff — The audio file is never passed to the gateway’s Telegram channel
No sendVoice call — No Telegram API call is initiated to deliver the voice note
Regression introduced in v2026.4.9 — The change from pre-v2026.4.9 behavior (corrupted delivery) to v2026.4.9 (no delivery) indicates a code regression in how the tts tool result is handled by the channel delivery layer

Pre-v2026.4.9 behavior: TTS generated audio but it was corrupted (appearing as long strings of exclamation marks in webchat).

v2026.4.9 behavior: TTS generates audio but delivers nothing at all.

The shift from “corrupted delivery” to “no delivery” suggests the audio file handling code path was either removed or broken during the v2026.4.9 update.

Solution

This is a code regression bug that requires a fix in the OpenClaw codebase. The following steps are needed:

Restore the sendVoice call path in the channel delivery layer — Ensure the audio file generated by the tts tool is properly passed to sendVoice for Telegram delivery
Verify audio file handling — Confirm the audio file path/content is correctly transferred between the tool result handler and the Telegram sender
Add integration tests for TTS→Telegram delivery to prevent future regressions
Fix STT handling — Ensure inbound voice notes are properly recognized and routed to the STT pipeline instead of being rejected as unsupported media types

Temporary Workaround:

Users may attempt to use the message tool with explicit media path for file attachment (untested)

Prevention

To prevent similar regressions in future releases:

Add automated TTS integration tests — Create end-to-end tests that verify voice notes are actually delivered to Telegram (not just that the tool reports success)
Test the full delivery pipeline — Ensure both generation AND delivery are tested together, not in isolation
Monitor channel delivery layer changes — Any modifications to how tool results are processed should include regression testing for media delivery
Log delivery confirmation — Add explicit logging when sendVoice is called to make failures more visible in logs
Multi-channel testing — Test TTS functionality when multiple channels (Telegram + webchat) are active simultaneously, as session handling issues may compound the problem

Additional Information

Affected versions: OpenClaw v2026.4.9 (updated 2026-04-09) and potentially later versions
Previous working behavior: Pre-v2026.4.9 had corrupted audio delivery
TTS Provider tested: ElevenLabs (eleven_multilingual_v2)
Channel: Telegram
Network connectivity: Confirmed working (text messages deliver successfully)
API credentials: ElevenLabs credentials verified functional via manual API calls
Multi-session factor: Session handling issues may contribute when Telegram and webchat are used simultaneously

Sources

GitHub Issue #64272

Agent-Sent TTS Audio Not Delivered via Webchat

Sun, 08 Mar 2026 00:00:00 +0000

Symptom

Agent-initiated TTS audio fails to reach webchat clients through two different paths:

Path 1: `tts` Tool

Agent calls the tts tool with text
textToSpeech() succeeds, audio file is created on disk (confirmed valid MP3)
Agent replies with NO_REPLY (as instructed by tool description)
No audio is delivered to the webchat client

Path 2: `[[tts]]` Tags

Agent includes [[tts]] or [[tts:text]]...[[/tts:text]] tags in a reply
During streaming, raw tags are visible in the UI (not processed)
After the run completes, no audio is delivered
Tags may remain visible as raw text in the final message

Working Path: `/tts audio`

User runs /tts audio Hello world
Audio is generated and delivered correctly on both webchat and Telegram

Root Cause Analysis

This is a regression caused by a mismatch between where audio is emitted and where it is processed in the reply delivery pipeline.

Root Cause 1: Block vs Final Payload Mismatch (`tts` tool path)

The issue lies in the disconnect between how pending tool media is emitted and how webchat processes replies:

Emission side (pi-embedded — handleAgentEnd → flushPendingMediaAndChannel): const pendingToolMediaReply = consumePendingToolMediaReply(ctx.state); if (pendingToolMediaReply && hasAssistantVisibleReply(pendingToolMediaReply)) ctx.emitBlockReply(pendingToolMediaReply); // ← emitted as “block” kind Audio is emitted as a “block” kind reply and queued in state.pendingToolMediaUrls.
Processing side (server.impl — webchat dispatch post-processing): const finalPayloads = deliveredReplies .filter((entry) => entry.kind === “final”) // ← blocks excluded .map((entry) => entry.payload); const audioBlocks = buildWebchatAudioContentBlocksFromReplyPayloads(finalPayloads); Webchat only extracts audio from “final” kind payloads, completely ignoring block payloads.

The block payload containing the audio file path is collected by the deliver callback but never processed for audio extraction. The audio file sits on disk, unused.

Root Cause 2: Auto-TTS Mode Skips Block Replies (`[[tts]]` tag path)

The auto-TTS mode defaults to "final", which causes block-kind replies to be skipped entirely:

// speech-core/runtime-api.js — maybeApplyTtsToPayload if ((config.mode ?? “final”) === “final” && params.kind && params.kind !== “final”) return nextPayload; // ← blocks skip TTS processing entirely

For streaming models, agent text is delivered incrementally as block replies, so [[tts]] tags pass through unprocessed during streaming.

A synthetic fallback exists in dispatch that attempts TTS on accumulated block text after the run completes:

// dispatch — after embedded run if (resolveConfiguredTtsMode(cfg) === “final” && replies.length === 0 && blockCount > 0 && accumulatedBlockText.trim()) { const ttsSyntheticReply = await maybeApplyTtsToReplyPayload({ payload: { text: accumulatedBlockText }, cfg, channel: ttsChannel, kind: “final”, … });

However, this fallback only fires when replies.length === 0 (no final replies returned from the embedded run). Whether the embedded run returns final replies depends on the model/provider implementation, making this path unreliable.

Solution

For `tts` tool path:

Modify server.impl to include block-kind payloads when extracting audio content blocks:

// server.impl — webchat dispatch post-processing // Before (broken): const finalPayloads = deliveredReplies .filter((entry) => entry.kind === “final”) .map((entry) => entry.payload);

// After (fixed): const allPayloads = deliveredReplies .map((entry) => entry.payload); const audioBlocks = buildWebchatAudioContentBlocksFromReplyPayloads(allPayloads);

For `[[tts]]` tag path:

Modify speech-core/runtime-api.js to process block-kind replies when in streaming mode:

// speech-core/runtime-api.js — maybeApplyTtsToPayload // Before (broken): if ((config.mode ?? “final”) === “final” && params.kind && params.kind !== “final”) return nextPayload;

// After (fixed): // Allow block-kind processing when streaming is active if (params.kind === “block” && !config.streamingMode) { return nextPayload; }

Alternatively, update the synthetic fallback in dispatch to be more robust regardless of whether final replies are present.

Prevention

Add integration tests that verify audio delivery for all TTS paths (tool, tags, and slash command) across all channels (webchat, Telegram).
Introduce a unified payload extraction function that processes both block and final kinds for audio content, preventing similar mismatches in the future.
Add QA checklist for TTS-related changes requiring verification that audio artifacts flow correctly from generation → emission → processing → delivery.
Document payload kind semantics clearly, especially the distinction between “block” and “final” kinds and which processing stages expect which kinds.

Additional Information

Affected version: 2026.3.7/2026.3.8
Operating system: Debian GNU/Linux 12 (bookworm)
Install method: Docker
Affected models: claude-opus-4.6, gpt-codex-5.4
Affected channels: web, telegram
Severity: Complete feature disablement (100% impact on agent-sent TTS)
Frequency: Always reproducible

The /tts audio slash command works correctly because it bypasses the embedded handler entirely and delivers audio through the standard final-payload path.

Sources

GitHub Issue #63033

GGML Metal Assertion Crash on Apple Silicon During Shutdown with Local Embeddings

Mon, 02 Mar 2026 00:00:00 +0000

Symptom

When running OpenClaw on Apple Silicon (M-series Macs) with local embeddings configured for memory search, the application crashes during shutdown (e.g., when receiving Ctrl+C / SIGINT or during autoupdate). The crash produces a GGML Metal assertion failure visible in the logs:

/Users/runner/work/node-llama-cpp/node-llama-cpp/llama/llama.cpp/ggml/src/ggml-metal/ggml-metal-device.m:608: GGML_ASSERT([rsets->data count] == 0) failed

The full stack trace shows the crash originates from ggml_metal_device_free being called during process exit, indicating that Metal resources were not properly released before shutdown.

Additionally, the following error may appear in the logs before the crash:

Unhandled promise rejection: AssertionError [ERR_ASSERTION]: Reached illegal state! IPV4 address change from defined to undefined!

This network-related error is a secondary symptom that occurs during the same shutdown sequence.

Affected Configurations:

macOS (all versions with Apple Silicon)
Local embeddings provider enabled via node-llama-cpp
Example configuration:

“agents”: { “defaults”: { “memorySearch”: { “provider”: “local”, “local”: { “modelPath”: “/path/to/embeddinggemma-…gguf” } } } }

Root Cause Analysis

The crash is caused by a resource leak in the interaction between OpenClaw and the node-llama-cpp library when using Metal GPU acceleration on Apple Silicon.

Technical Details

Embedding Context Lifecycle: When local embeddings are used, node-llama-cpp creates embedding contexts that hold Metal GPU resources (textures, buffers, and command queues managed by GGML Metal).
Missing Disposal on Shutdown: During normal process exit (SIGINT, SIGTERM, or autoupdate restart), these embedding contexts are not explicitly disposed before the Node.js event loop terminates. This leaves Metal resources in an active state.
GGML Metal Unload Assertion: When the process exits, llama.cpp’s ggml_metal_device_free() function runs during the atexit() phase. This function asserts that all Metal resource sets (rsets->data) have been released. Since the embedding contexts were not disposed, this assertion fails: GGML_ASSERT([rsets->data count] == 0)
Regression Indicator: This issue is classified as a regression because the functionality worked in previous versions, suggesting a change in either OpenClaw’s shutdown handling, node-llama-cpp’s behavior, or a combination of both.

Call Chain

process.exit() → exit() [libsystem_c.dylib] → __cxa_finalize_ranges() → ggml_metal_device_free() [libggml-metal.so] → GGML_ASSERT([rsets->data count] == 0) // FAILS HERE

Solution

Implement a cleanup patch that tracks embedding contexts and explicitly disposes them before process exit.

Step 1: Create the Cleanup Patch File

Create a new file at src/memory/local-cleanup-patch.ts:

import { getLlama } from ’node-llama-cpp';

const trackedContexts: any[] = [];

const originalCreate = getLlama.prototype.createEmbeddingContext; getLlama.prototype.createEmbeddingContext = async function (…args: any[]) { const ctx = await originalCreate.apply(this, args); trackedContexts.push(ctx); return ctx; };

async function cleanup() { if (trackedContexts.length === 0) return; console.log([cleanup] Disposing ${trackedContexts.length} embedding context(s)); for (const ctx of trackedContexts) { if (ctx?.dispose) { await ctx.dispose().catch(e => console.warn(’[cleanup] Dispose failed:’, e)); } } trackedContexts.length = 0; }

process.once(‘SIGINT’, cleanup); process.once(‘SIGTERM’, cleanup); process.on(‘beforeExit’, cleanup);

export { cleanup };

Step 2: Modify the Import Function

Update src/memory/node-llama.ts to automatically apply the cleanup patch when local embeddings are used:

export async function importNodeLlamaCpp() { // Automatically apply our shutdown fix when local embeddings are used await import(’./local-cleanup-patch’); return import(“node-llama-cpp”); }

Step 3: Verify the Fix

After implementing the changes:

Restart the OpenClaw service
Trigger an autoupdate or send SIGINT (Ctrl+C)
Confirm the application shuts down gracefully without GGML Metal assertion failures

Prevention

To prevent this issue from recurring:

Always Test Shutdown Sequences: When integrating libraries that manage native resources (GPU, CUDA, Metal), always test graceful shutdown scenarios including SIGINT, SIGTERM, and forced exits.
Implement Resource Tracking: For any async resource allocation (embedding contexts, model instances), implement tracking mechanisms that can be flushed during shutdown.
Register Cleanup Handlers Early: Register shutdown cleanup handlers (process.once('SIGINT'), process.once('SIGTERM'), process.on('beforeExit')) as early as possible in the application lifecycle.
Use Graceful Shutdown Patterns: Implement a unified shutdown manager that coordinates cleanup across all subsystems, ensuring native resources are released before the event loop terminates.
Add Regression Tests: Consider adding automated tests that verify graceful shutdown behavior on all supported platforms, particularly Apple Silicon with Metal GPU acceleration.

Additional Information

Temporary Workarounds

If the fix cannot be applied immediately, use one of the following workarounds to disable Metal GPU acceleration:

Option 1: Disable GPU layers entirely export NODE_LLAMA_CPP_GPU_LAYERS=0

Option 2: Disable Metal specifically (version-dependent) export NODE_LLAMA_CPP_METAL=false

Note: These workarounds will reduce embedding performance but prevent the crash.

Affected Versions

OpenClaw 2026.3.1 is confirmed affected
Earlier versions may also be affected depending on the node-llama-cpp version in use

node-llama-cpp: Embedding context management
ggml-metal (llama.cpp): Metal GPU resource management
@homebridge/ciao: mDNS/network management (secondary error source during shutdown)

External References

GGML Metal device cleanup: llama.cpp PR #17869
Setting GGML_BACKTRACE_LLDB may cause native MacOS Terminal.app to crash; use with caution

Sources

GitHub Issue #32452

Regression on FixClaw

Chrome Exits Immediately After OpenClaw Launch on Windows 11 - CDP Never Binds

Symptom

Root Cause Analysis

Solution

Workaround 1: Use attachOnly Mode

Workaround 2: Launch Chrome Before OpenClaw Operations

Prevention

Wait for browser to be ready

Additional Information

Sources

TTS Voice Note Delivery Regression in v2026.4.9

Symptom

Root Cause Analysis

Solution

Prevention

Additional Information

Sources

Agent-Sent TTS Audio Not Delivered via Webchat

Symptom

Path 1: tts Tool

Path 2: [[tts]] Tags

Working Path: /tts audio

Root Cause Analysis

Root Cause 1: Block vs Final Payload Mismatch (tts tool path)

Root Cause 2: Auto-TTS Mode Skips Block Replies ([[tts]] tag path)

Solution

For tts tool path:

For [[tts]] tag path:

Prevention

Additional Information

Sources

GGML Metal Assertion Crash on Apple Silicon During Shutdown with Local Embeddings

Symptom

Root Cause Analysis

Technical Details

Call Chain

Solution

Step 1: Create the Cleanup Patch File

Step 2: Modify the Import Function

Step 3: Verify the Fix

Prevention

Additional Information

Temporary Workarounds

Affected Versions

Related Dependencies

External References

Sources

Path 1: `tts` Tool

Path 2: `[[tts]]` Tags

Working Path: `/tts audio`

Root Cause 1: Block vs Final Payload Mismatch (`tts` tool path)

Root Cause 2: Auto-TTS Mode Skips Block Replies (`[[tts]]` tag path)

For `tts` tool path:

For `[[tts]]` tag path: