[Bug]: Built-in browser denies microphone access to web pages

[juliusmarminge]

Originally filed as issue #18970 by @bjesuiter: #18970

---

Before submitting

• I searched existing issues and did not find a duplicate.
• I included steps and a result from the current desktop preview.

Area

apps/desktop, built-in browser preview

Problem

Web pages in T3 Code's built-in browser cannot obtain microphone input. This blocks testing WebRTC/audio-capture applications inside the preview.

Steps to reproduce

1. Open https://webrtc.github.io/samples/src/content/getusermedia/gum/ in T3 Code's built-in browser.
2. In that page, call navigator.permissions.query({ name: "microphone" }) and navigator.mediaDevices.getUserMedia({ audio: true }).

Actual behavior

In T3 Code Nightly 0.0.46-nightly.20261012.3021 on macOS 26.7.1, the HTTPS page reports isSecureContext === true and navigator.mediaDevices exists, but the microphone permission state is denied. getUserMedia({ audio: true }) rejects with NotSupportedError: Not supported. No grant path is offered to the user.

Expected behavior

A page should be able to request microphone access with an origin-specific user prompt, then capture audio after the user grants the relevant macOS and site permissions. The user should be able to revoke the grant.

Likely cause

The Electron preview session's permission request and check handlers return ALLOWED_PREVIEW_PERMISSIONS.has(permission). The allowlist omits media, so media capture requests are denied. See BrowserSession.ts on current main and the handlers. The behavior was reproduced in the preview; the source points to the likely reason but was not debugged at runtime.

Related reports

• fix(tauri): prompt before preview origins capture media #12566 concerns origin prompts in the Tauri/WKWebView preview and explicitly says the Electron preview path is outside its scope.
• macOS: apps launched from integrated terminal can't request TCC permissions (mic, camera) #728 and [Feature]: T3 never requests macOS microphone/camera permission, so it can never be granted - blocks all voice/vision MCP tooling #7242 concern permissions for processes launched from T3 Code, not web pages in the built-in browser.

Workaround

Open the application in an external browser for microphone testing.

[jR4dh3y]

Consolidating the camera use case and proposal here, as requested in #19284. This is a feature/RFC, not a bug report. Direction and scope approval are still needed before a PR proceeds. The implementation in #19285 remains a reference; I am closing that premature PR and the duplicate issue while the discussion is pending.

Embedded camera use case

An Infosys Springboard system check requests a camera from https://lex-iap.infosysapps.com, embedded in https://infyspringboard.onwingspan.com. The original preview reported camera permission as denied with no user-facing grant path. This is the same underlying media policy reported here for microphone access.

Proposed consent model

• Show a native Allow/Deny prompt before media capture, naming the requesting site, the top-level site when different, and the requested devices. Deny is the default and cancel action.
• Keep decisions in memory, separate for camera and microphone, each browser profile, and each top-level/requesting origin pair. An existing camera approval does not approve a later microphone request.
• Reset future decisions when T3 closes or the user clears that profile's cookies/site data. Closing a capturing tab stops its active stream. Resetting decisions alone does not terminate an already-running stream.
• Reject opaque/insecure origins and unknown device types. Reject overlapping prompts and discard stale approvals after top-level navigation, tab closure, or profile reset. Requesting-subframe navigation still needs native runtime validation.
• Keep media out of the unconditional permission allowlist. Both Electron request and check handlers consult the same consent decisions.
• Include the necessary macOS usage descriptions and app/helper entitlements if that platform is included in the approved scope. Signed macOS behavior still needs verification.

This does not forward a remote client's webcam into a streamed/headless browser or change provider, web/mobile, or wire permissions.

Local prototype evidence

The user supplied this screenshot after running the Linux development checkout. It shows the requested camera, both origins, and the Allow/Deny controls:

The screenshot establishes that the dialog appeared. The user subsequently confirmed that clicking Allow delivered camera video in the local Linux development build. This is user-reported manual verification; the agent did not independently observe the stream or retain a capture recording. The screenshot predates the final macOS helper-entitlement packaging adjustment; the dialog implementation is unchanged.

The prototype passes 104 focused tests, desktop/scripts typechecks, touched-file lint, and desktop bundle generation. A new consent test fails against unmodified main at the grant assertion and passes with the implementation. These are policy tests with mocked Electron callbacks, not physical-device proof.

Microphone capture, a complete before/after screenshot pair, requesting-subframe navigation, Windows runtime, and signed macOS TCC/helper behavior remain unverified. No exam completion or remote webcam support is claimed.

Direction requested

Would maintainers accept this direction and scope, particularly the session-only decisions and reset mechanism, or prefer dedicated per-site permission controls or a smaller initial scope? I will keep the implementation on my fork while approval is pending and adjust it to the agreed scope.