Desktop in-app browser: Google Home live cameras fail while Chrome works (SDP/ICE compatibility leads)

Google Home live camera streams fail in the desktop in-app browser while Chrome plays them

Product and environment

• OpenAI desktop app's Codex in-app browser / sidecar on macOS.
• Installed app bundle: ChatGPT.app, version 26.915.31029, build 9771 (bundle identifier com.openai.codex).
• macOS 27.0.
• Site: https://home.google.com/ (signed-in camera grid).
• Reproduced in the current investigation on September 17, 2026; an earlier investigation recorded the same symptom on August 23, 2026.

Steps to reproduce

1. Open Google Home in the desktop app's in-app browser and sign in to an account with working live cameras.
2. Open the Cameras grid and attempt to view live feeds.
3. Open the same account and camera grid in external Google Chrome on the same machine.
4. Compare playback; retry a failed live feed in the in-app browser.

Expected behavior

Live camera streams play in the in-app browser, as they do in external Chrome.

Actual behavior and current observations

• The in-app browser authenticates, lists the cameras, and loads the Google Home application, but working cameras show "Unable to play media" / "Couldn't load video".
• Retrying a working camera's live view did not resolve the failure.
• External Chrome played four live feeds in the comparison. The other two cameras were idle/offline and are excluded from the failure claim.
• DOM inspection found all six in-app-browser video elements paused with readyState 0. The four working Chrome feeds had paused=false and readyState 4.
• Captured ordinary application/API requests succeeded. We did not isolate a current network or console error that identifies the precise failing WebRTC operation.
• The user additionally reports that the same cameras play in Claude's embedded sidecars for both Claude Code and Cowork. This is user-reported comparison evidence, not independently re-tested in this investigation.

Earlier diagnostic findings: useful leads, not revalidated against the current build

The retained August 23 investigation summary records:

• App version 26.818.41509 and embedded Chromium 151.0.7922.170.
• Clearing browsing data and restarting did not fix playback. Login, camera discovery, route resolution, and ordinary RPCs worked.
• Basic WebRTC/H.264 capability checks did not explain the difference from Chrome.
• Stream setup stopped inside Google's WebRTC player (then minified as a.gs(...)) before /v1/join_stream.
• Temporarily removing goog-sped-v1 from the SDP allowed setLocalDescription(), /v1/join_stream, and receipt of live tracks. This was diagnostic instrumentation, not a successful workaround.
• ICE still failed: no selected candidate pair or inbound RTP in the embedded browser, while Chrome selected a pair. The recorded states included connectionState=failed and iceConnectionState=disconnected.
• The temporary patch was restored.

These details are recovered from a prior investigation summary, not fresh measurements or attached raw traces. They should be treated as engineering leads for reproduction, not proof that the current release fails at exactly the same point.

Suggested engineering investigation

The evidence points to an embedded-browser/WebRTC interoperability issue. Please compare the desktop browser's SDP handling, libwebrtc build/runtime configuration, and ICE transport behavior against working Chrome. In particular, investigate the historical goog-sped-v1 negotiation issue and the separate failure to nominate an ICE candidate pair after signaling progressed.

The precise current underlying defect remains unconfirmed. This report does not establish missing codecs, missing WebRTC support, or a general limitation of embedded browsers. The automation evaluator hides browser globals in its read-only scope, so its capability booleans were excluded as invalid evidence.

No camera imagery, private home/device identifiers, credentials, IP addresses, session transcripts, or raw network logs are included.

No source file or test is named. Reproduce the failure, then compare SDP handling and ICE transport in the embedded browser against Chrome, focusing on the historical goog-sped-v1 lead, the minified Google player entry point a.gs(...), and /v1/join_stream. Done means identifying and fixing the current interoperability defect so live camera feeds play and an ICE candidate pair is nominated.