feat(mcp): support python, java and csharp in --codegen

[Pavel Feldman (pavelfeldman)]

Summary

• --codegen now accepts python, java and csharp in addition to typescript and none
• tools emit structured actions (@isomorphic/codegen/actions) rendered with the recorder language generators when serializing the response; operations without an action representation keep their JavaScript snippets
• secrets render as idiomatic environment lookups per language (process.env[...], os.environ[...], System.getenv(...), Environment.GetEnvironmentVariable(...)), with a SECRET_<NAME> placeholder fallback

Fixes microsoft/playwright-mcp#1696

[github-actions]

Test results for "tests 1"

3 flaky

⚠️ [chromium-library] › library/video.spec.ts:699 › screencast › should capture full viewport on hidpi `@frozen-time-library-chromium-linux`
⚠️ [chromium-library] › library/chromium/chromium.spec.ts:177 › serviceWorker(), and fromServiceWorker() work `@realtime-time-library-chromium-linux`
⚠️ [firefox-page] › page/page-goto.spec.ts:90 › should work with Cross-Origin-Opener-Policy `@firefox-ubuntu-22.04-node20`

51196 passed, 1188 skipped

---

Merge workflow run.

[github-actions]

Test results for "MCP"

1 failed
❌ [firefox] › mcp/cli-parsing.spec.ts:76 › should preserve leading zeros in string arguments @mcp-windows-latest-firefox

8049 passed, 1284 skipped

---

Merge workflow run.

[github-actions]

Hi, I'm the Playwright bot and I took a first look at the CI failures here.

🟡 One MCP failure — uncertain, can't prove it either way

[firefox] › mcp/cli-parsing.spec.ts:76 › should preserve leading zeros in string arguments failed once on mcp-windows-latest-firefox (run 30862424062). The typed value never showed up in the snapshot (Expected substring "0812345679", received "- textbox [ref=e2]"). The tests 1 run is clean — only flaky/interrupted, nothing to triage there.

Details

Overall: the only real failure is a single MCP test on one bot. This PR does touch the tools that test exercises (keyboard.ts/type, snapshot.ts), so I can't wave it off — but the runtime path the test asserts on is unchanged, and I found no prior failure to call it a flake. Net: uncertain.

Uncertain

• [firefox] › mcp/cli-parsing.spec.ts:76 › should preserve leading zeros in string arguments — the test types 0812345679 and expects it back in the accessibility snapshot; the textbox came back empty, so the fill didn't register on this run.
  • Argument against caused-by-PR: your change to the type tool is emission-only — response.addAction({ name: 'fill', ... }) replaced response.addCode(...). The actual interaction, await locator.fill(secret.value, ...), and the snapshot rendering are byte-identical to main. The assertion is on the DOM value, not on emitted code, so the diff doesn't obviously reach the failing behavior. A real regression here would also be expected to hit chromium/webkit, not one firefox-windows shard.
  • Argument against flake: per the triage hard rule I need the same test failing where the PR can't be responsible, and there isn't any. On mcp-windows-latest-firefox this test is 351/352 green — the one red is this PR's run, and it's green across every other bot (~7000 runs). It has never flaked in the window the DB covers.
  • To be sure: re-run the MCP job on this branch. A pass on retry with no code change would confirm it's a timing flake in fill→snapshot rather than something you introduced.

Run history on mcp-windows-latest-firefox (oldest→newest, last square is this PR):

…🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟥

_{Triaged by the Playwright bot - agent run}