feat(mcp): accept ConnectOptions object for remoteEndpoint#40964
Merged
Conversation
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
Skn0tt
reviewed
May 27, 2026
| * `remoteEndpoint` is provided as a [ConnectOptions] object; supply | ||
| * `headers` on that object instead. | ||
| */ | ||
| remoteHeaders?: Record<string, string>; |
Member
There was a problem hiding this comment.
Let's remove this - almost nobody uses it so it's fine to be a little breaking.
Contributor
Author
There was a problem hiding this comment.
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.
pavelfeldman
approved these changes
May 29, 2026
This comment has been minimized.
This comment has been minimized.
Member
|
@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.
Contributor
Test results for "MCP"1 failed 7229 passed, 1103 skipped Merge workflow run. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
remoteEndpointwas a plain URL string, so there was no way to forwardexposeNetwork,headers,slowMo, ortimeoutwhen connecting to a remote browser.exposeNetwork: '<loopback>'is the standard way to let the remote browser reachlocalhoston the client (via SOCKS tunneling), and is what the test runner already supports viaconnectOptionsinplaywright.config.ts.string | playwright.ConnectOptions & { endpoint: string }per @dgozman's suggestion on the original attempt. The string form keeps existing behavior; the object form is normalized insidecreateRemoteBrowserand passed straight through toconnectToBrowser.Fixes #40478