openclaw - ✅(Solved) Fix Google Meet tool-created realtime sessions can lose gateway ownership [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

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#72440Fetched 2026-04-27 05:30:07
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
Participants
Timeline (top)
cross-referenced ×1

When the google_meet agent tool creates or joins a realtime Google Meet room, the live session can be owned only by the tool-turn plugin runtime instead of the gateway-owned googlemeet.* runtime. After the agent turn completes, googlemeet.status, googlemeet.leave, and googlemeet.speak can no longer see that session, even though the Chrome tab and node audio bridge continue running.

Error Message

In a live OpenClaw 2026.4.24 install:

Root Cause

  1. An agent used google_meet action create with join: true, transport: chrome-node, mode: realtime.
  2. The tool result returned a session id and initial same-turn google_meet status could report realtime readiness.
  3. After the agent turn ended, openclaw gateway call googlemeet.status --params '{"sessionId":"..."}' returned { "found": false } and googlemeet.status listed no active sessions.
  4. The Chrome Meet tab and BlackHole/SoX node bridge processes were still running.
  5. Tool-backed live conversation then stalled because the official gateway control path no longer owned the session.

Fix Action

Fix / Workaround

On a patched OpenClaw 2026.4.24 install, an agent-created Google Meet room through the real google_meet tool stayed visible to googlemeet.status after the agent turn completed. A direct create/leave smoke after node-host cleanup left no BlackHole SoX bridge processes running.

PR fix notes

PR #72441: Fix Google Meet tool session ownership

Description (problem / solution / changelog)

Summary

  • Route stateful google_meet agent tool actions through the Google Meet gateway methods so create/join/status/leave/speak/test_speech/recover calls share the gateway-owned plugin runtime instead of creating tool-turn-local sessions.
  • Preserve structured gateway error details while keeping the legacy Google Meet error payload shape for manual-action responses.
  • Harden node-host command-pair cleanup so already-closed sessions still terminate child bridge processes, with SIGTERM then SIGKILL fallback.

Fixes #72440.

Validation

  • pnpm exec oxfmt --check extensions/google-meet/index.ts extensions/google-meet/index.test.ts extensions/google-meet/index.create.test.ts extensions/google-meet/src/test-support/plugin-harness.ts extensions/google-meet/src/node-host.ts
  • pnpm exec vitest run extensions/google-meet/index.test.ts extensions/google-meet/index.create.test.ts
  • pnpm tsgo:extensions:test
  • git diff --check

Live runtime smoke evidence

  • Jay tool-created room https://meet.google.com/krq-swpp-kik / meet_40603aaf-6587-4527-80a5-502b598f9e27 remained visible to googlemeet.status after the Jay tool turn ended, with providerConnected: true and realtimeReady: true.
  • Direct create/leave smoke https://meet.google.com/hcz-ftus-qhy / meet_7a5d75ee-b5dc-46ad-ab86-aaee35381cc7 left no lingering SoX bridge processes after googlemeet.leave.

Notes

This PR complements, rather than replaces, the earlier bridge-orphan and Gemini function-response fixes. The observed production failure was that sessions created by the agent tool path were not owned by the gateway process after the tool turn returned.

Changed files

  • extensions/google-meet/index.create.test.ts (modified, +16/-3)
  • extensions/google-meet/index.test.ts (modified, +16/-3)
  • extensions/google-meet/index.ts (modified, +99/-46)
  • extensions/google-meet/src/node-host.ts (modified, +18/-5)
  • extensions/google-meet/src/test-support/plugin-harness.ts (modified, +45/-0)
RAW_BUFFERClick to expand / collapse

Summary

When the google_meet agent tool creates or joins a realtime Google Meet room, the live session can be owned only by the tool-turn plugin runtime instead of the gateway-owned googlemeet.* runtime. After the agent turn completes, googlemeet.status, googlemeet.leave, and googlemeet.speak can no longer see that session, even though the Chrome tab and node audio bridge continue running.

Observed behavior

In a live OpenClaw 2026.4.24 install:

  1. An agent used google_meet action create with join: true, transport: chrome-node, mode: realtime.
  2. The tool result returned a session id and initial same-turn google_meet status could report realtime readiness.
  3. After the agent turn ended, openclaw gateway call googlemeet.status --params '{"sessionId":"..."}' returned { "found": false } and googlemeet.status listed no active sessions.
  4. The Chrome Meet tab and BlackHole/SoX node bridge processes were still running.
  5. Tool-backed live conversation then stalled because the official gateway control path no longer owned the session.

Expected behavior

Stateful google_meet tool actions should use the registered googlemeet.* gateway methods so that the same gateway runtime owns session maps, speak/leave callbacks, and health checks after the agent turn exits.

Additional bridge cleanup issue found during verification

While verifying the fix, googlemeet.leave could still leave one side of the node command-pair audio bridge alive. The cause is stopSession() returning early when session.closed is already true; if one child process closes first, the later official stop path skips termination of the surviving child. Also, Node's child.killed flag only means a signal was sent, not that the process exited, so SIGKILL fallback should check exitCode/signalCode.

Fix in PR

  • Routes stateful google_meet tool actions (join, create, test_speech, status, recover_current_tab, setup_status, leave, speak) through the existing gateway methods.
  • Preserves structured Google Meet gateway error payloads in protocol error.details, while keeping legacy gateway payload shape for direct gateway handlers.
  • Hardens node command-pair cleanup so both child processes are always signaled, even if the bridge was already marked closed, and escalates from SIGTERM to SIGKILL based on process exit state.

Local validation

  • pnpm exec oxfmt --check extensions/google-meet/index.ts extensions/google-meet/index.test.ts extensions/google-meet/index.create.test.ts extensions/google-meet/src/test-support/plugin-harness.ts extensions/google-meet/src/node-host.ts
  • pnpm exec vitest run extensions/google-meet/index.test.ts extensions/google-meet/index.create.test.ts
  • pnpm tsgo:extensions:test

Live smoke validation

On a patched OpenClaw 2026.4.24 install, an agent-created Google Meet room through the real google_meet tool stayed visible to googlemeet.status after the agent turn completed. A direct create/leave smoke after node-host cleanup left no BlackHole SoX bridge processes running.

extent analysis

TL;DR

Route stateful google_meet tool actions through existing gateway methods to ensure the gateway runtime owns session maps and callbacks.

Guidance

  • Verify that the google_meet tool actions are correctly routed through the gateway methods by checking the session ownership after the agent turn completes.
  • Ensure that the googlemeet.status command can still see the session after the agent turn ends.
  • Test the googlemeet.leave command to confirm that it properly cleans up the node command-pair audio bridge.
  • Validate the fix using the provided local and live smoke validation commands.

Example

No code snippet is provided as the issue does not require a specific code change, but rather a routing change through existing gateway methods.

Notes

The fix involves routing stateful google_meet tool actions through existing gateway methods, which should resolve the issue of the gateway not owning the session after the agent turn completes. However, additional cleanup issues may still exist, such as the node command-pair audio bridge not being properly terminated.

Recommendation

Apply the workaround by routing stateful google_meet tool actions through existing gateway methods, as this should resolve the primary issue of session ownership and allow for proper cleanup of the node command-pair audio bridge.

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…

FAQ

Expected behavior

Stateful google_meet tool actions should use the registered googlemeet.* gateway methods so that the same gateway runtime owns session maps, speak/leave callbacks, and health checks after the agent turn exits.

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix Google Meet tool-created realtime sessions can lose gateway ownership [1 pull requests, 1 participants]