Skip to content

feat(mcp): accept ConnectOptions object for remoteEndpoint#40964

Merged
Skn0tt merged 3 commits into
microsoft:mainfrom
adityasingh2400:fix-40478
Jun 1, 2026
Merged

feat(mcp): accept ConnectOptions object for remoteEndpoint#40964
Skn0tt merged 3 commits into
microsoft:mainfrom
adityasingh2400:fix-40478

Conversation

@adityasingh2400
Copy link
Copy Markdown
Contributor

Summary

  • remoteEndpoint was a plain URL string, so there was no way to forward exposeNetwork, headers, slowMo, or timeout when connecting to a remote browser. exposeNetwork: '<loopback>' is the standard way to let the remote browser reach localhost on the client (via SOCKS tunneling), and is what the test runner already supports via connectOptions in playwright.config.ts.
  • Accept string | playwright.ConnectOptions & { endpoint: string } per @dgozman's suggestion on the original attempt. The string form keeps existing behavior; the object form is normalized inside createRemoteBrowser and passed straight through to connectToBrowser.

Fixes #40478

The CLI / MCP config exposed `remoteEndpoint` as a plain URL string, so
there was no way to forward `exposeNetwork`, `headers`, `slowMo`, or
`timeout` when connecting to a remote browser. The test runner already
accepts a `connectOptions` object via `playwright.config.ts`; this brings
the same surface to the MCP config.

`remoteEndpoint` now accepts `string | playwright.ConnectOptions & {
endpoint: string }`. The string form keeps the existing behavior. The
object form is normalized inside `createRemoteBrowser` and forwarded to
`connectToBrowser`, so the underlying connect call receives the full set
of options including `exposeNetwork: '<loopback>'` for SOCKS tunneling
back to the client.

Fixes: microsoft#40478
Copy link
Copy Markdown
Member

@Skn0tt Skn0tt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

* `remoteEndpoint` is provided as a [ConnectOptions] object; supply
* `headers` on that object instead.
*/
remoteHeaders?: Record<string, string>;
Copy link
Copy Markdown
Member

@Skn0tt Skn0tt May 27, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's remove this - almost nobody uses it so it's fine to be a little breaking.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. I removed the remoteHeaders field along with its handling, the --remote-header CLI flag, and the PLAYWRIGHT_MCP_REMOTE_HEADERS env var. Headers for a remote connect now go through the ConnectOptions object form of remoteEndpoint. Updated the tests to match.

Drops the remoteHeaders config field, the --remote-header CLI flag, and
the PLAYWRIGHT_MCP_REMOTE_HEADERS env var. Headers for a remote connect
are now supplied through the ConnectOptions object form of remoteEndpoint.
@github-actions

This comment has been minimized.

@Skn0tt
Copy link
Copy Markdown
Member

Skn0tt commented Jun 1, 2026

@copilot can you update the failing tests?

The test specified the remote endpoint twice - positionally to attach
and inside the config's remoteEndpoint object - relying on undefined
merge behaviour between the CLI-forwarded --endpoint= string and the
object form in the config file.

Coverage of the ConnectOptions-object remoteEndpoint (with headers) is
already provided by tests/mcp/remote-endpoint.spec.ts.
@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented Jun 1, 2026

Test results for "MCP"

1 failed
❌ [webkit] › mcp/http.spec.ts:103 › http transport browser lifecycle (isolated) @mcp-ubuntu-latest-webkit

7229 passed, 1103 skipped


Merge workflow run.

@Skn0tt Skn0tt merged commit 899c7a5 into microsoft:main Jun 1, 2026
17 of 18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Feature] exposeNetwork not supported for remote browser connections in CLI config

3 participants