openclaw - 💡(How to fix) Fix Webchat mic button broken — Permissions-Policy header blocks microphone access [1 participants]

Official PRs (…)
ON THIS PAGE

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#62299Fetched 2026-04-08 03:06:25
View on GitHub
Comments
0
Participants
1
Timeline
0
Reactions
0

Error Message

navigator.mediaDevices.getUserMedia({audio: true}) // → NotAllowedError: Permissions policy violation: microphone is not allowed in this document.

Root Cause

The gateway server sends this response header:

Permissions-Policy: camera=(), microphone=(), geolocation=()

microphone=() blocks all microphone access on the page. The Web Speech Recognition API fails with not-allowed, and the error handler silently swallows it with no user feedback.

Code Example

Permissions-Policy: camera=(), microphone=(), geolocation=()

---

navigator.mediaDevices.getUserMedia({audio: true})
// → NotAllowedError: Permissions policy violation: microphone is not allowed in this document.

---

res.setHeader("Permissions-Policy", "camera=(), microphone=(), geolocation=()");

---

res.setHeader("Permissions-Policy", "camera=(), microphone=(self), geolocation=()");
RAW_BUFFERClick to expand / collapse

Bug

The webchat UI includes a voice input (speech-to-text) mic button, but it silently fails — clicking it does nothing.

Root Cause

The gateway server sends this response header:

Permissions-Policy: camera=(), microphone=(), geolocation=()

microphone=() blocks all microphone access on the page. The Web Speech Recognition API fails with not-allowed, and the error handler silently swallows it with no user feedback.

Steps to Reproduce

  1. Open the webchat UI (e.g. http://127.0.0.1:18789/chat)
  2. Click the mic button
  3. Nothing happens — no prompt, no error, no recording indicator

Running this in the browser console confirms:

navigator.mediaDevices.getUserMedia({audio: true})
// → NotAllowedError: Permissions policy violation: microphone is not allowed in this document.

Suggested Fix

In the gateway server (server-*.js), change:

res.setHeader("Permissions-Policy", "camera=(), microphone=(), geolocation=()");

to:

res.setHeader("Permissions-Policy", "camera=(), microphone=(self), geolocation=()");

This allows the webchat's own origin to use the microphone while still blocking third-party/embedded contexts.

Additional Note

The mic button's error handler also silently swallows errors — it might be worth surfacing a user-visible message when speech recognition fails (e.g. "Microphone access denied").

extent analysis

TL;DR

Update the Permissions-Policy header in the gateway server to allow microphone access for the webchat's own origin by changing microphone=() to microphone=(self).

Guidance

  • Verify that the Permissions-Policy header is being set correctly by checking the response headers from the gateway server.
  • Test the updated header by running navigator.mediaDevices.getUserMedia({audio: true}) in the browser console to ensure that microphone access is allowed.
  • Consider updating the mic button's error handler to display a user-visible error message when speech recognition fails, such as "Microphone access denied".
  • Review the webchat UI's implementation to ensure that it properly handles cases where microphone access is denied or fails.

Example

// Updated code in server-*.js
res.setHeader("Permissions-Policy", "camera=(), microphone=(self), geolocation=()");

Notes

This fix assumes that the webchat UI is running on the same origin as the gateway server. If the webchat UI is embedded in a third-party context, additional configuration may be necessary to allow microphone access.

Recommendation

Apply the suggested fix by updating the Permissions-Policy header to allow microphone access for the webchat's own origin. This should resolve the issue while still maintaining security restrictions for third-party contexts.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING