Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
#4,931 1 comentário 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
45/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
javascript, node.js, playwright

Direção de pesquisa

The issue is in the cloud agent's MCP session management for the built-in Playwright server. Start by examining the coordinator's connection through the bridge at 127.0.0.1:2301 and the error 'Using deferred connection for default Playwright server'. Look at the MCP proxy bridge code and session lifecycle logs to see why the transport closes before the first tool call. Verify the error handling for closed sessions to ensure it doesn't incorrectly report OAuth for localhost. Check if there's a shared root cause with issue #4378 involving the registry policy.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

triage
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 #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 #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 #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. #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

Linguagem predominante
Shell
Estrelas
11.2k
Forks
1.9k
Merge médio
14h 16min
PRs com merge (30d)
6

Guia de contribuição

Abrir o guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de github/copilot-cli

Todas as issues de github/copilot-cli

Issues semelhantes

Mais issues de Shell/Bash

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.