react-grab already ships an agent round-trip — should Cmux wire it up?

[giuseppebisemi]

I went digging through the internal-browser comment flow (react-grab, Cmd+Shift+G) and hit something worth checking with you before I write any code.

Right now Cmux uses react-grab one way. Sources/Panels/ReactGrab.swift registers a plugin with onStateChange and onCopySuccess, so a comment goes to the agent through the clipboard or a paste into the terminal, and the panel just says "Copied".

The pinned react-grab@0.1.29 bundle already has more than that. It ships an agent-provider API with a round-trip built in. Register a plugin that carries an agent.provider and react-grab starts showing live agent status ("Completed" instead of "Copied"), follow-up replies, and presence. That UI already exists in the library. You can see the surface in the bundle: setHasAgentProvider, setAgentCapabilities({ supportsUndo, supportsFollowUp, dismissButtonText, isAgentConnected }), provider.send(prompt, signal) plus resume, undo, checkConnection, and sessions that carry lastStatus. The provider gets picked up by for (s of store.actions) if (s.agent?.provider). Cmux just never registers one.

One catch worth flagging: that agent-provider API looks gone in react-grab@0.1.44. The project seems to have moved to a clipboard plus external CLI pull/watch model instead. So wiring 0.1.29's in-library provider means leaning on an API you might already be planning to drop.

If it's worth doing, the payoff is turning the in-browser comments from one-way capture into an actual review loop, with status, replies, and presence landing back on the comment. The bridge would connect react-grab's provider to Cmux's AgentSessionProvider (.claude/.codex/.opencode) over a WKScriptMessageHandlerWithReply.

So the question is which direction you'd want:

1. Wire 0.1.29's agent provider as a feature-detected enhancement. Register it only when the embedded react-grab exposes the provider API, otherwise fall back to today's clipboard path. Smallest change, no version freeze, and it degrades to current behavior on any future bump.
2. Follow react-grab's newer CLI pull/watch model and build the round-trip UI on the Cmux side.
3. Build a Cmux-native round-trip layer on the existing comment panel, independent of react-grab's churn.
4. None of these right now.

I'd lean toward option 1 since it's additive and easy to back out. I've already reverse-engineered the 0.1.29 provider interface and read through the current ReactGrab.swift integration, so I can take whichever one you point me at.