Playwright Extension: client name always shows as "unknown" on the token-bypass connect path

[dosxnjos]

Problem

When an MCP client connects to the Playwright Extension via the token-bypass path (setting
PLAYWRIGHT_MCP_EXTENSION_TOKEN so the connection dialog doesn't need a manual click), the
connect page and the status page ("Connected to X") always show the client name as "unknown",
regardless of what name the client actually declares. The tab-picker connection path (clicking
"Allow & select") shows the real client name correctly.

Confirmed on upstream/main, unmodified - not specific to any fork or downstream change.

Root cause

In packages/extension/src/ui/connect.tsx, handleConnectToTab is a useCallback that reads the
client name from clientInfo React state:

const handleConnectToTab = useCallback(async (tab?: chrome.tabs.Tab) => {
  ...
  clientName: clientInfo,
  ...
}, [clientInfo]);

On the token-bypass path, it's called synchronously within the same effect run that just called
setClientInfo(info):

const info = `${client.name || 'unknown'}`;
setClientInfo(info);
...
if (token === expectedToken) {
  await handleConnectToTab();  // still closes over the initial 'unknown' clientInfo
  return;
}

setClientInfo only schedules a re-render; it doesn't mutate the clientInfo variable already
captured by the version of handleConnectToTab this effect closed over at mount. So this call
always sees the initial 'unknown' state, never the freshly-parsed info. The tab-picker path
doesn't hit this, since a user click can only happen after at least one render has already landed
with the updated clientInfo.

This is deterministic (not a timing race) and independent of what client name is actually passed -
reproduces the same way regardless.

Proposed fix

Pass the freshly-parsed name explicitly as an argument at the token-bypass call site instead of
relying on the closure - e.g. give handleConnectToTab an optional second parameter and pass
info directly there, leaving the tab-picker call site (which doesn't have this problem) unchanged.
Small, isolated, single-file fix. Happy to open a PR if this approach sounds right.

[dosxnjos]

Small addition while I had this open: MCP clients often identify themselves with a
program-style name (e.g. claude-code) rather than one meant for display. Once the
"unknown" bug above is fixed and the real name actually reaches the UI, it's worth
title-casing kebab/snake-case client names for display (claude-code → Claude Code)
rather than showing the raw identifier verbatim - a no-op for names that are already
display-ready. Happy to include this in the same PR as a small follow-up, or keep it
separate if you'd rather review them independently.

[dosxnjos]

Retracting my suggestion above about title-casing the client name for display. On reflection,
that loses precision on exactly what tab-group labeling exists to preserve: distinct raw names
that only differ in separator convention (e.g. "claude-code" vs "claude_code") would render
identically once title-cased, making it harder to tell different clients/tools apart. Showing
the name exactly as the client declares it is the better default - no changes needed beyond the
original "unknown" fix.

[cipheraxat]

I'd like to take this issue and send a fix.

Root cause matches the report: the token-bypass path calls `handleConnectToTab()` in the same effect that just called `setClientInfo(info)`, so the callback still closes over the initial `'unknown'` state. Planned fix is to pass the freshly parsed client name into `handleConnectToTab` at that call site, plus a regression test on the existing token-bypass extension coverage that asserts the status page shows the real client name.

Could this be assigned to me?