Skip to content

[MCP]: browser_start_video drops the directory for videos recorded from additional tabs #41659

Description

@takeyaqa

What's going on?

When asking an MCP client to start video recording with a filename that includes a directory path, videos recorded for newly opened tabs are written to a different directory than the first video.

MCP client: Claude Code
MCP server config: --caps=devtools

Steps to reproduce

In an AI agent chat, ask the agent to do the following:

  1. Start video recording and save it as recordings/video.webm.

    • Expected tool call: browser_start_video
    • Expected arguments: { "filename": "recordings/video.webm" }
  2. Open a new browser tab.

    • Expected tool call: browser_tabs
    • Expected arguments: { "action": "new" }
  3. Stop video recording.

    • Expected tool call: browser_stop_video
    • Expected arguments: {}

Actual behavior

The first tab's video is saved under the requested directory, but the newly opened tab's video is saved outside that directory:

recordings/video.webm
video-1.webm

Expected behavior

The video for the newly opened tab should be saved next to the first video, preserving the directory part of the requested filename:

recordings/video.webm
recordings/video-1.webm

Question about the intended behavior

browser_start_video accepts filename, and the first video appears to support a path that includes directories. For additional tabs, should Playwright MCP preserve the directory and only add the numeric suffix to the basename?

In other words, should this be fixed to save additional tab videos in the same directory, or is the intended API that filename should not include directories in the first place?

I am happy to send a PR either way, once the intended behavior is confirmed.

Version

1.61.1 / 0.0.77

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions