Summary

Chrome-node Google Meet realtime sessions can leave the node-side command-pair audio bridge alive after the gateway/plugin-side session registry loses ownership. A later join for the same Meet URL can start a second node bridge while the stale SoX/BlackHole pair keeps running. Separately, one transient pullAudio node invoke failure currently tears down the realtime bridge immediately, leaving the Meet tab joined but unresponsive.

Why this looks like a beta blocker

The documented Google Meet plugin supports realtime Chrome/Chrome-node participation and the documented node host is the supported way to run browser/audio work on another machine. In a real private Meet session, a gateway restart/state loss plus transient node timeout produced:

• gateway googlemeet.status returning no sessions while the node-side SoX bridge processes were still alive
• repeated rejoins creating multiple open Meet tabs/bridge pairs
• the browser participant staying in-call after realtime audio stopped responding

Docs:

• Google Meet plugin: https://docs.openclaw.ai/plugins/google-meet
• Node host: https://docs.openclaw.ai/cli/node

Local evidence from reproduced incident

Runtime: OpenClaw 2026.4.24 on macOS, Google Meet plugin, transport=chrome-node, mode=realtime, Google realtime provider using gemini-3.1-flash-live-preview.

Observed process split:

• gateway/plugin GoogleMeetRuntime owns only process-local #sessions, #sessionStops, and #sessionHealth
• persistent node host owns actual googlemeet.chrome command-pair bridge sessions and SoX children in its own process-local sessions map
• join only reuses sessions visible to the gateway map
• leave can only stop sessions still visible to the gateway map
• node-host stopSession only sent SIGTERM and exposed status by bridge id; there was no list/gc/stop-by-url action for orphaned node bridge cleanup
• realtime-node.ts stopped on the first pullAudio exception, including transient node invoke timeouts

Expected behavior

• Joining the same Meet URL over chrome-node should reconcile/clean stale node-side bridge ownership before starting a fresh command-pair bridge.
• Node host should expose lifecycle inspection/cleanup for Google Meet bridge sessions by URL/mode so gateway recovery is possible.
• Transient input-pull failures should be tolerated for a short window; hard bridge loss or repeated failures should still stop cleanly.
• Stopping a node bridge should escalate beyond SIGTERM if SoX children do not exit.

Patch

I opened a PR from BsnizND:fix/google-meet-node-bridge-orphans that:

• adds node-host list and stopByUrl actions for googlemeet.chrome
• stores Meet URL/mode metadata on node bridge sessions
• cleans same-URL/same-mode stale node bridge sessions before chrome-node starts a new bridge
• adds SIGTERM then SIGKILL escalation for child audio processes
• tolerates transient node pullAudio failures up to 5 consecutive failures and surfaces consecutiveInputErrors / lastInputError in chrome health
• adds focused Google Meet extension tests

Validation:

• pnpm exec oxfmt --check extensions/google-meet/src/node-host.ts extensions/google-meet/src/realtime-node.ts extensions/google-meet/src/transports/chrome.ts extensions/google-meet/src/transports/types.ts extensions/google-meet/index.test.ts
• pnpm exec vitest run extensions/google-meet/index.test.ts
• pnpm tsgo:extensions:test