feat(mcp): add --file-paths=absolute for absolute paths in tool results - #42673
Conversation
| options.executablePath = envToString(e.PLAYWRIGHT_MCP_EXECUTABLE_PATH); | ||
| options.extension = envToBoolean(e.PLAYWRIGHT_MCP_EXTENSION); | ||
| if (e.PLAYWRIGHT_MCP_FILE_PATHS) | ||
| options.filePaths = enumParser<'relative' | 'absolute'>('--file-paths', ['relative', 'absolute'], e.PLAYWRIGHT_MCP_FILE_PATHS); |
There was a problem hiding this comment.
| options.filePaths = enumParser<'relative' | 'absolute'>('--file-paths', ['relative', 'absolute'], e.PLAYWRIGHT_MCP_FILE_PATHS); | |
| options.filePaths = enumParser<'relative' | 'absolute'>('PLAYWRIGHT_MCP_FILE_PATHS', ['relative', 'absolute'], e.PLAYWRIGHT_MCP_FILE_PATHS); |
|
Copilot resolve the merge conflicts in this pull request |
This comment has been minimized.
This comment has been minimized.
0a6193b to
a6dd5ad
Compare
Test results for "MCP"2 failed 8575 passed, 1446 skipped Merge workflow run. |
🟢 Both failures are known Windows/Firefox flakes — the PR is clearHi, I'm the Playwright bot and I triaged the CI failures here. Both reds are on DetailsThe diff is confined to how paths are formatted in MCP tool results ( Pre-existing flake / infra
Both look like timing margins on the Windows/Firefox bot rather than anything this PR introduced. Triaged by the Playwright bot - agent run |
49d290a
into
microsoft:main
…s red @playwright/mcp 0.0.81 pins playwright-core 1.64.0-alpha-2026-09-14 exactly, and the first build carrying --file-paths=absolute, the filePaths config key and PLAYWRIGHT_MCP_FILE_PATHS is 1.64.0-alpha-2026-09-17 (microsoft/playwright#42673, merged 2026-09-16, closing this project's own ask #42497). build/payload/package.json now carries an npm `overrides` entry that pulls that one build forward underneath the wrapper. That collides with "everything floats and the build freezes it; never pin to work around a break", so it is taken as a DATED EXCEPTION with a written exit rather than absorbed: the entry is deleted the day @playwright/mcp `latest` pins a playwright-core at or above the override. Two independent instruments hold the exit, and both were watched red. PayloadTests.TheDatedPlaywrightCoreOverrideIsStillNeeded reads the committed lock, so it runs from a clean clone on every build; build/Build-Payload.ps1 reads the live resolution and refuses to assemble a payload past the exit. Each carries its own ordering of upstream's two published shapes and refuses any third rather than guessing a shape it cannot order is lower. Planted red twice. The test, against a lock doctored so the wrapper already pins the override: TheDatedPlaywrightCoreOverrideIsStillNeeded and TheAssembledManifestDeclaresWhatTheCommittedLockRecords both failed, the first naming the file and the key to delete. The script, against an override lowered to the declared pin: exit 1 with THE OVERRIDE'S EXIT HAS FIRED. Both green on the real files, 12 passed / 0 failed / 0 skipped. TheLockRecordsUpstreamsOwnExactPinOfPlaywrightCore keeps the half the override rests on -- upstream still pinning EXACTLY -- and its `declared == resolved` half moved to TheResolvedPlaywrightCoreIsWhateverTheOverrideSays, which is where the override is compared. npm writes no `overrides` block into the lock, measured 2026-09-17, so the manifest is the only record that one is in force. Resolution proved rather than assumed: the lock names playwright-core 1.64.0-alpha-2026-09-17 with npm's own integrity hash, coreBundle.js holds 2 occurrences of PLAYWRIGHT_MCP_FILE_PATHS against 0 at the old pin, and the running child's --help carries `--file-paths <mode>`.
Summary
--file-paths <mode>option,relative(default) orabsolute, also available asfilePathsin the config file and viaPLAYWRIGHT_MCP_FILE_PATHSabsolute, file links, the console log link, the download line and the paused location are rendered as absolute pathsFixes #42497