Summary
We use the superpowers-chrome browsing skill to drive Claude Code agents through real web workflows. A recurring need we can't currently satisfy with the plugin is recording the agent's browsing as a video — for demos, showcases, bug repros, and documentation. Today the plugin can take a screenshot (a single still), but there's no way to capture a continuous recording of what the agent is doing in the tab.
We'd like a first-class screencast capability so an agent (or a human driving the CLI) can record a tab to a video file.
Why this matters / use cases
- Demos & showcases. When we show off an agent completing a task end-to-end, a stitched-together set of screenshots doesn't convey the flow. A short MP4 of the actual session is far more compelling and is what stakeholders ask for.
- Bug reproductions. "It broke somewhere in this multi-step flow" is much easier to file and review as a 10-second clip than as prose plus stills.
- Documentation & onboarding. Recording golden-path flows once and embedding the clip keeps docs honest and current.
- Regression evidence. Pairing a recording with the existing auto-capture artifacts gives a visual record alongside the HTML/MD/console snapshots.
Screenshots alone can't cover these — timing, transitions, animations, and "what happened between steps" are exactly the information a still loses.
What the feature should do
- Start/stop recording the active tab and produce a video file (MP4 is the natural default).
- Be exposed both as MCP actions (the primary agent path) and as a CLI command, matching how
screenshot is surfaced today.
- Save to the auto-capture session directory by default (timestamped name), with an optional explicit output path — mirroring
screenshot's path resolution so it feels consistent.
- Preserve real timing of the session rather than assuming a fixed frame rate.
Suggested approach (implementation-friendly)
Chrome DevTools Protocol already provides everything needed without adding npm dependencies:
Page.startScreencast streams individual frames via Page.screencastFrame events; each frame must be acked with Page.screencastFrameAck or Chrome stops sending. This is the same event-stream pattern the plugin already uses for console logging (Runtime.consoleAPICalled), so it fits the existing architecture cleanly.- Assembling frames into a video is the client's job. Shelling out to ffmpeg to mux the frames (using each frame's
metadata.timestamp for accurate, variable-interval timing) keeps the zero-runtime-dependency stance. This matches the plugin's existing best-effort system-tool pattern — screenshot.js already shells out to sips/ImageMagick for downscaling with a silent fallback. If ffmpeg isn't installed, the raw frame sequence can be left on disk and its path reported, so the feature degrades gracefully rather than hard-failing.
One design note worth calling out: the MCP server caches one page session per tab for its whole lifetime, so a frame listener registered on start is still alive when a later stop call arrives — start and stop can share in-process state, exactly like the console-logging buffers do.
Willing to contribute
We've prototyped this against the current architecture and are happy to open a PR (lib module + MCP actions + CLI command + unit tests + docs). Filing this issue first to confirm the feature is wanted and to align on the shape before review.
Summary
We use the superpowers-chrome browsing skill to drive Claude Code agents through real web workflows. A recurring need we can't currently satisfy with the plugin is recording the agent's browsing as a video — for demos, showcases, bug repros, and documentation. Today the plugin can take a
screenshot(a single still), but there's no way to capture a continuous recording of what the agent is doing in the tab.We'd like a first-class screencast capability so an agent (or a human driving the CLI) can record a tab to a video file.
Why this matters / use cases
Screenshots alone can't cover these — timing, transitions, animations, and "what happened between steps" are exactly the information a still loses.
What the feature should do
screenshotis surfaced today.screenshot's path resolution so it feels consistent.Suggested approach (implementation-friendly)
Chrome DevTools Protocol already provides everything needed without adding npm dependencies:
Page.startScreencaststreams individual frames viaPage.screencastFrameevents; each frame must be acked withPage.screencastFrameAckor Chrome stops sending. This is the same event-stream pattern the plugin already uses for console logging (Runtime.consoleAPICalled), so it fits the existing architecture cleanly.metadata.timestampfor accurate, variable-interval timing) keeps the zero-runtime-dependency stance. This matches the plugin's existing best-effort system-tool pattern —screenshot.jsalready shells out tosips/ImageMagick for downscaling with a silent fallback. If ffmpeg isn't installed, the raw frame sequence can be left on disk and its path reported, so the feature degrades gracefully rather than hard-failing.One design note worth calling out: the MCP server caches one page session per tab for its whole lifetime, so a frame listener registered on
startis still alive when a laterstopcall arrives — start and stop can share in-process state, exactly like the console-logging buffers do.Willing to contribute
We've prototyped this against the current architecture and are happy to open a PR (lib module + MCP actions + CLI command + unit tests + docs). Filing this issue first to confirm the feature is wanted and to align on the shape before review.