Cloud agent: the built-in Playwright MCP session is already closed at the first tool call, and recovery reports it as browser OAuth required

[CynthiaLuijkx]

Describe the bug

Split out of #4378, which carries two faults. The registry policy 401 in that issue has a cause and a workaround. This one does not, and it survives that workaround.

Summary

In a Copilot cloud agent session on a GHEC data residency tenant (<tenant>.ghe.com), every call to a playwright/* tool fails. The Playwright server is healthy for the whole session. The coordinator's MCP session to it is not. The second error message is wrong and sends a reader after a sign-in problem that does not exist.

The built-in Playwright MCP server is enabled by default and is documented as needing no setup. It is unusable here.

Reproduction

Any session in any repository on the tenant. Serve any page on localhost and call playwright/browser_navigate. It needs no repository-specific state.

First call:

MCP server 'playwright': Tool call failed: Error: MCP request failed: Transport closed

Recovery attempt:

MCP server 'playwright': Tool call failed after session recovery:
MCPOAuthBrowserRequiredError: Browser-based OAuth required for http://localhost:3100/mcp

The second message is misleading. The server is on localhost, it is unauthenticated, and it needs no sign-in of any kind.

The server is healthy throughout

• It runs from /opt/copilot-runtime on the runner image's own Node 24.
• It listens on port 3100 for the whole session.
• A direct MCP initialize answers HTTP 200 and reports Playwright MCP 0.0.40.
• The coordinator retrieves all 21 of its tools at session start, and they appear in the agent's tool list.

By the time the agent calls a tool, the coordinator's MCP session to that server is already closed. The recovery request gets HTTP 404, because the session no longer exists. The client then enters OAuth handling for an unauthenticated localhost server.

The coordinator does not talk to the Playwright server directly

The coordinator connects through a bridge process, not to port 3100:

/opt/hostedtoolcache/node/24.20.0/x64/bin/node \
  /opt/copilot-runtime/copilot-developer-action-main/dist-cca-v3/mcp-proxy-bridge.js \
  --proxy-url=http://127.0.0.1:2301 --server-name=playwright

The peer it initializes against names itself accordingly:

[INFO]  Created session: <redacted>
[ERROR] Using deferred connection for default Playwright server
[INFO]  [rust:rmcp::service] Service initialized as client
  peer_info: Implementation { name: "mcp-proxy-bridge/playwright", version: "1.0.0" }

Three things follow.

• Using deferred connection for default Playwright server is logged at ERROR level, 216 milliseconds after the session is created, before the bridge initializes. It is the only error in the runtime lifecycle log.
• 127.0.0.1:2301 is the same internal MCP proxy named in Cloud agent: MCP registry policy fetch fails with 401/403 on GHEC data residency, silently blocking all user-configured MCP servers #4378.
• The transport that closes is the coordinator's connection through that bridge. It is not a connection to Playwright.

Session lifetime: the server is not the cause

I created an MCP session against port 3100 by hand and held it idle.

initialize                          HTTP/1.1 200 OK
                                    serverInfo: {"name":"Playwright","version":"0.0.40"}
notifications/initialized           HTTP/1.1 202 Accepted
tools/list immediately              HTTP/1.1 200 OK   (21 tools)
tools/list after 120 seconds        HTTP/1.1 200 OK   (21 tools)
tools/list after 420 seconds        HTTP/1.1 200 OK   (21 tools)
GET /mcp opened then killed         (stream closed by the client)
tools/list after that close         HTTP/1.1 200 OK   (21 tools)

No 404 at any point. The Playwright server does not expire an idle session, and it does not drop a session when the client closes the SSE stream. Whatever closes the coordinator's transport is above the server.

It is not a timing problem either

I called playwright/browser_navigate with about:blank as the very first action of a session, before reading a file and before any shell command. It failed with the same two errors. So the transport is not closed by the agent's own work, and calling the browser early is not a workaround.

Ruled out, with evidence

• The SDK token 401 of Cloud agent: MCP registry policy fetch fails with 401/403 on GHEC data residency, silently blocking all user-configured MCP servers #4378. The failure persists with the Agents variable GH_HOST=<tenant>.ghe.com set and no 401 anywhere in the runtime log.
• The Node version the repository installs. actions/setup-node puts Node 26 on GITHUB_PATH for the shell. The runtime starts its MCP servers on the image's own Node 24. The two never meet.
• An environment variable holding a personal access token. The first failing session carried none, and the failure survived renaming the secret.
• The application under test. The frontend served correctly on http://localhost:4200 in the same session.
• An egress proxy with no localhost exclusion. The runtime process carries no HTTP_PROXY, HTTPS_PROXY, ALL_PROXY or NO_PROXY variable in any case.
• The Playwright server expiring the session. See the lifetime table above.
• The agent taking too long before the first call. See the first-action test above.

What I could not find reported anywhere

There is no report of MCP request failed: Transport closed against the built-in default Playwright server, and no report of Browser-based OAuth required for http://localhost:3100/mcp. Every public MCPOAuthBrowserRequiredError I found is a genuine remote OAuth server.

What I ask for

1. The cause of the transport closing. It is closed before the agent's first action, so it is not an idle timeout and not the agent's doing.
2. A correct error for a closed MCP session. The current message tells a customer to sign in to an unauthenticated localhost server, which is neither possible nor needed.
3. Whether this and Cloud agent: MCP registry policy fetch fails with 401/403 on GHEC data residency, silently blocking all user-configured MCP servers #4378 share a root cause at 127.0.0.1:2301. GITHUB_COPILOT_3P_MCP_POLICY_ENABLED is true in this session, and the only ERROR in the lifecycle log is the deferred connection line.
4. Whether Using deferred connection for default Playwright server is expected. It is logged at ERROR level. [RFC] autoConnect: false — Deferred MCP Server Registration + On-Demand Lifecycle Init #1938 is an open request for deferred connection as a feature, which suggests it is not yet a settled behavior.
5. If the built-in Playwright server is not expected to work on a .ghe.com tenant, document it. The data residency feature overview lists no such limitation today.

Impact

The built-in browser is the intended route for a Copilot cloud agent to look at a page it changed. On this tenant it never works. Session ids and full runtime logs are available on request.

Affected version

No response

Steps to reproduce the behavior

No response

Expected behavior

No response

Additional context

No response

[Hronom]

The evidence here points to two independent health signals that should not be collapsed into one recovery path:\n\n- endpoint health: the Playwright process is listening and can answer initialize/tools-list;\n- binding health: the coordinator/bridge session is still attached to that endpoint and session generation.\n\nA closed binding with a healthy endpoint should be classified as a transport/session-lifecycle failure and retried through re-initialize/re-attach—not as OAuth. In particular, an arbitrary local 401/404 or a closed stream should not enter browser-based OAuth handling unless an actual authentication challenge was observed for that target.\n\nIt would help to carry values-free provenance through the error: server/bridge identity, MCP session generation, request id, target origin and the last verified lifecycle state. Then the first browser call can distinguish “server was healthy, coordinator binding closed before dispatch” from “endpoint was unreachable” or “authentication was required.” The user-facing message can point to the affected layer without suggesting sign-in to an unauthenticated localhost service.\n\nFor browser effects, I would also keep requested, dispatched, observed and verified separate, and return an explicit unknown/reconciliation-required outcome when the transport closes after dispatch but before an independent read-back. A regression matrix covering first-call failure, bridge restart, server restart, idle hold, real OAuth, localhost without auth and tenant/proxy variants should prevent the recovery classifier from regressing.\n\nI maintain Hronaut, a local visible Browser/MCP workspace, and this is AI-assisted technical feedback—not a Copilot CLI or Playwright compatibility claim.