Greptile Summary

This PR adds URL/mode metadata to node-host bridge sessions, introduces list and stopByUrl node-host actions, sends a pre-join stopByUrl cleanup in launchChromeMeetOnNode, upgrades child-process teardown to SIGTERM→SIGKILL with a 2 s grace window, and makes the pullAudio loop tolerate up to 4 transient failures before tearing down the realtime session. The changes are tightly scoped and the lifecycle logic is sound; tests cover the new recovery and cleanup paths.

Confidence Score: 4/5

Safe to merge; only a minor API-clarity issue with listSessions returning closed sessions.

No P0 or P1 issues found. The single P2 observation (listSessions returning closed sessions without documentation) does not affect correctness or the new lifecycle paths described in the PR.

No files require special attention.

This is a comment left during a code review.
Path: extensions/google-meet/src/node-host.ts
Line: 360-368

Comment:
**`listSessions` returns closed sessions**

`listSessions` includes sessions where `closed === true`, so a caller filtering for active sessions to stop (or display) would silently include already-terminated entries. The summary object exposes a `closed` field, so callers can post-filter, but the `list` action docs/contract don't make this explicit. Consider filtering out closed sessions by default or accepting a `closed` filter parameter to avoid confusion.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "Fix Google Meet chrome-node bridge clean..." | Re-trigger Greptile}

Codex automated review: keeping this open.

Keep this PR open. Current main still has the Google Meet chrome-node lifecycle gap the PR targets: the gateway runtime owns only process-local session maps, node-host bridge sessions do not carry URL/mode metadata, node-host has no list/stop-by-URL action, launch starts a new node bridge without reconciling stale same-URL bridges, and realtime input stops on the first pullAudio failure. The PR is a focused implementation candidate paired with open beta-blocker #72371, and the bot review only raised a minor list-session semantics concern.

Best possible solution:

Keep this PR open as the implementation candidate for open beta-blocker #72371. Review the node-host list/stopByUrl API semantics, address or consciously accept the Greptile P2 comment, then run the focused Google Meet tests and a chrome-node smoke before landing.

What I checked:

• Current main node-host lacks URL/mode cleanup API: NodeBridgeSession only tracks bridge/process/audio state, stopSession only sends SIGTERM, and the googlemeet.chrome action switch supports setup/start/status/pullAudio/pushAudio/stop but no list or stopByUrl action. (extensions/google-meet/src/node-host.ts:14, d3fd275aa5fc)
• Current main starts chrome-node without stale bridge reconciliation: launchChromeMeetOnNode resolves the node, opens/reuses the browser tab, then invokes googlemeet.chrome start directly; there is no pre-start stopByUrl cleanup path. (extensions/google-meet/src/transports/chrome.ts:603, d3fd275aa5fc)
• Current main tears down realtime input on first pull failure: The paired-node realtime loop catches any pullAudio invoke error, logs it, and immediately calls stop(), so transient node failures can end an otherwise healthy session. (extensions/google-meet/src/realtime-node.ts:173, d3fd275aa5fc)
• Gateway ownership is process-local: GoogleMeetRuntime stores sessions, stop handlers, speakers, and health callbacks in private in-memory maps; join reuse and leave cleanup depend on those maps, so lost gateway/plugin state cannot enumerate node-host bridges on current main. (extensions/google-meet/src/runtime.ts:73, d3fd275aa5fc)
• Existing tests do not cover the proposed stale-node cleanup/retry behavior: Current tests for same-URL chrome-node reuse expect only one googlemeet.chrome invocation, and the paired-node audio test covers the happy path rather than transient pullAudio recovery or repeated-failure shutdown. (extensions/google-meet/index.test.ts:1395, d3fd275aa5fc)
• PR context shows a relevant open paired beta-blocker: The PR body uses closing syntax for Beta blocker: google-meet chrome-node realtime bridges can orphan and stop on transient input failure #72371, and the related issue is still open with beta-blocker label. The provided PR metadata shows head commit 08e1428b8062cfd42c92ae631f9061155f26c39c and focused changes in the Google Meet plugin files. (08e1428b8062)

Remaining risk / open question:

• Greptile's review comment about listSessions returning closed sessions should be resolved or explicitly accepted before merge so the new inspection API has clear semantics.
• Because this is a node-host command contract change, maintainers should consider mixed gateway/node versions; the PR context indicates pre-join cleanup errors are ignored, which is the right compatibility direction.
• A live chrome-node smoke would still be valuable after code review because this path depends on Chrome, BlackHole/SoX audio routing, and node-host process lifecycle.

Codex Review notes: model gpt-5.5, reasoning high; reviewed against d3fd275aa5fc.

Landed in f2a17b299119b426d7542cefe8848f8f69535c42.

What changed after review:

• tightened googlemeet.chrome list so closed node-host bridge sessions are not reported as active
• kept stopByUrl idempotent for already-closed matching sessions
• added regression coverage for the closed-session listing/cleanup path
• kept the contributor-facing changelog attribution

Remote proof, no local test lanes:

• GitHub CI 24980121791 passed on d583a6b615e9e181086fb22035ace43ce3de02ea
• Blacksmith Testbox tbx_01kq6t5jk2f51gxq30j9veyjhy passed focused Google Meet formatting and tests: extensions/google-meet/node-host.test.ts + extensions/google-meet/index.test.ts, 51 tests

Thanks @BsnizND.