Every open-source project has two kinds of work: the kind that gets retweeted and the kind that makes the software actually usable. LangChain ships the first kind weekly. OpenClaw, this week, shipped both. Nobody noticed the second kind. Let's fix that.
Matrix Users Were Getting Audio Files Instead of Voice Messages
OpenClaw supports text-to-speech across its messaging channels. When a user has TTS enabled, the agent converts its text response into audio and sends it as a voice message. On Telegram, WhatsApp, and Feishu, this works beautifully — you get a native voice bubble with a waveform visualization and inline playback controls. It looks like a human sent a voice note.
On Matrix, you got a file attachment. A generic download link. No waveform. No inline player. No indication that this was supposed to be a voice message at all. It looked like your AI agent was emailing you an MP3 from 2004.
The fix, by contributor Matthew19990919 and merged by gumadeiras, is exactly one line: add "matrix" to the VOICE_BUBBLE_CHANNELS set in src/tts/tts.ts. That's it. The Matrix extension already fully supported MSC3245 voice bubbles — opus encoding, waveform metadata, duration tags, everything. The TTS pipeline just didn't know to activate it.
“The Matrix channel plugin already fully supports voice bubbles via extensions/matrix/src/matrix/send.ts. The missing configuration entry prevented resolveOutputFormat() from applying voice-compatible settings.”
— PR #37080 description
I want to underline something: this bug existed because someone built the Matrix voice bubble implementation, tested it, shipped it, and then forgot to register the channel name in a separate file's configuration set. The feature was complete. The wiring was missing. For approximately 1,500 Matrix users with auto-TTS enabled, every voice response was degraded because of a string that wasn't in a Set.
This is the kind of bug that integration testing catches and unit testing doesn't. And it's the kind of bug that open-source projects accumulate when the contributor who builds a feature and the contributor who maintains the configuration are different people on different continents.
Linux nvm Installs Were Silently Breaking HTTPS
This one is uglier and it took longer to find.
If you installed OpenClaw on Linux using nvm-managed Node.js — which is how most VPS deployments work — every web_fetch operation failed silently. No error. No warning. The agent just couldn't reach the internet. Issue #49088 tracked the problem: nvm's Node.js binary doesn't automatically inherit the system CA certificate bundle, so TLS handshakes fail against every HTTPS endpoint.
The system-installed Node.js on Ubuntu, Fedora, or SUSE comes pre-linked against the distro's certificate store. Nvm's binary doesn't. It's a well-known footgun in the Node.js ecosystem and it bites people constantly. The fix is setting NODE_EXTRA_CA_CERTS to point at the system CA bundle. But knowing that and automating it are different things.
Contributor GodsBoy's fix, merged by steipete, does the automation properly. During install or upgrade, OpenClaw now:
- Detects nvm by checking for the
NVM_DIRenvironment variable or/.nvm/in the Node.js executable path - Probes three distro-specific certificate paths:
/etc/ssl/certs/ca-certificates.crtfor Debian/Ubuntu,/etc/pki/tls/certs/ca-bundle.crtfor RHEL/Fedora, and/etc/ssl/ca-bundle.pemfor openSUSE - Writes
NODE_EXTRA_CA_CERTSto both the systemd service environment and~/.openclaw/.env - Returns undefined and writes nothing if no CA bundle exists at any probed path
The implementation injects platform and execPath parameters for testability, and the suite includes 65 passing tests covering every probe combination and upgrade path. It even backfills the .env during upgrades without requiring --force.
What These Fixes Have in Common
Neither of these bugs crashed anything. Neither corrupted data. Neither triggered an alert. They both degraded the experience for a specific subset of users who probably assumed the behavior was normal — or assumed it was their fault.
That's the worst category of bug in open-source software: the kind where users blame themselves. “Maybe Matrix just doesn't support voice well.” “Maybe I misconfigured my VPS.” No. The software was wrong. It just wasn't wrong loudly enough for anyone to file it as a bug for months.
The fact that both fixes shipped in the same sprint as the plugin boundary enforcement and the compaction budget overhaul says something about where OpenClaw is right now. The project is simultaneously cleaning up architecture, fixing invisible user-experience regressions, and closing platform gaps. That breadth is either a sign of a healthy contributor base or a sign of accumulated neglect finally getting addressed. It's probably both.
“You can tell a lot about a project by how it treats the users who aren't on the default path. Matrix users. Linux nvm users. If those people get fixes, the project is paying attention. If they don't, it's just chasing stars.”
Full details: PR #37080 (Matrix voice) and PR #51146 (Linux TLS) on GitHub. Both fixes are live for DeployClaw users.