iframe-proxy

MukundaKatta · 2026-05-29T07:51:50Z

Summary

openclaw doctor on Windows reports Could not determine the installed Chrome version. Chrome MCP requires Google Chrome 144+ on this host. even when a supported Chrome (e.g. 148.0.7778.179) is installed at the standard path and the browser tool itself connects and works fine. See [Bug]: openclaw doctor reports "Could not determine the installed Chrome version" despite Chrome 148 installed at expected path #87312.
Root cause: readBrowserVersion() resolves the version by running chrome.exe --version. On macOS/Linux that prints the version to stdout, but on Windows the GUI binary does not attach to the parent console, so --version produces no stdout and detection returns null.
Fix: add a win32 branch to readBrowserVersion() that reads the version from the Chromium install layout (the newest sibling Application\<version> build directory), falling back to the executable's file metadata via PowerShell ProductVersion for non-standard/portable layouts. This mirrors the existing darwin branch, which already reads the app bundle Info.plist instead of --version.
Out of scope: the minimum-version policy and the macOS/Linux code paths are unchanged.
Success: on Windows, doctor detects Chrome 144+ and stops emitting the false warning; other platforms behave exactly as before.
Reviewer focus: the new readWindowsBrowserVersion() helper and the win32 branch in readBrowserVersion() in extensions/browser/src/browser/chrome.executables.ts.

Linked context

Closes #87312

Was this requested by a maintainer or owner? No; community bug report.

Real behavior proof (required for external PRs)

Behavior or issue addressed: doctor false positive "Could not determine the installed Chrome version" on Windows with a working Chrome install.
Real environment tested: macOS (development host). The Windows-specific path was exercised by unit tests, not on a live Windows host (I do not have a Windows machine available).
Exact steps or command run after this patch:
- pnpm test extensions/browser/src/browser/chrome.version.test.ts
- pnpm test extensions/browser/src/doctor-browser.test.ts
- pnpm tsgo, oxlint, oxfmt --check on the touched files
Evidence after fix:
- New on Windows unit tests in chrome.version.test.ts stub process.platform = "win32" and build a real temporary directory mirroring the Application\<version> install layout. They assert that readBrowserVersion():
  - derives the newest version from sibling build directories using numeric (not lexical) ordering, and does not spawn PowerShell when a version directory exists;
  - falls back to powershell.exe ... (Get-Item -LiteralPath '<exe>').VersionInfo.ProductVersion when no version directory exists;
  - returns null when neither signal is available.
- Results: chrome.version.test.ts 6 passed; doctor-browser.test.ts 11 passed; tsgo 0 errors; oxlint 0 errors; oxfmt --check clean.
Observed result after fix: on the simulated Windows layout readBrowserVersion() returns e.g. 148.0.7778.179, so parseBrowserMajorVersion() yields 148 >= 144 and doctor would not emit the warning.
What was not tested: a live Windows host with a real Chrome install. The PowerShell command was not executed against a real chrome.exe; the fallback is covered via a mocked execFileSync.
Proof limitations: I cannot run Windows locally, so the version-directory layout and the PowerShell ProductVersion fallback are validated by unit tests and the well-documented Chromium-on-Windows --version behavior rather than a live run. Live confirmation on a Windows host would strengthen this PR; happy to adjust if a maintainer can reproduce.

clawsweeper · 2026-05-29T07:54:05Z

Codex review: needs real behavior proof before merge. Reviewed June 29, 2026, 5:18 PM ET / 21:18 UTC.

Summary
The branch adds a Windows-specific browser version reader that checks sibling Chromium build directories, falls back to PowerShell ProductVersion metadata, adds mocked version-reader tests, and adds a changelog entry.

PR surface: Source +60, Tests +59, Docs +1. Total +120 across 3 files.

Reproducibility: yes. at source level, but not live in this review: current main warns when readBrowserVersion returns null, matching the linked Windows Chrome 148 report. I did not establish a live Windows reproduction.

Review metrics: 1 noteworthy metric.

Windows version fallback: 1 existing fallback bypassed on win32. The PR returns from the new Windows helper before the public version reader reaches the shipped generic --version probe, so compatibility needs explicit review.

Stored data model
Persistent data-model change detected: migration/backfill/repair: CHANGELOG.md, vector/embedding metadata: CHANGELOG.md, vector/embedding metadata: extensions/browser/src/browser/chrome.version.test.ts. Confirm migration or upgrade compatibility proof before merge.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #87312
Summary: This PR is a candidate fix for the canonical Windows Browser doctor false-warning issue; the sibling PR overlaps but is not a safe supersession because it is still open and proof-blocked.

Members:

canonical: [Bug]: openclaw doctor reports "Could not determine the installed Chrome version" despite Chrome 148 installed at expected path #87312 - The issue describes the same Windows Chrome 148 doctor false warning and GitHub lists this PR as a closing candidate.
fixed_by_candidate: fix(browser): read Chrome version from PE metadata on Windows #87344 - The sibling PR also uses closing syntax for the canonical issue with a PE ProductVersion approach, but it remains open and lacks inspectable real Windows proof.
adjacent_distinct: Doctor: Chrome version detection is flaky on macOS due to Gatekeeper cold-cache latency (2s timeout too tight) #85418 - This closed issue used the same warning text but was about macOS Gatekeeper cold-cache timeout behavior rather than Windows metadata detection.
adjacent_distinct: fix(browser): avoid cold mac chrome version timeouts #85460 - This merged PR fixed the macOS Info.plist-first path and increased fallback timeout, but it did not add Windows ProductVersion or build-directory detection.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🦪 silver shellfish
Result: blocked until real behavior proof from a real setup is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

[P1] Add redacted live Windows openclaw doctor proof showing Chrome 144+ detected after this patch.
Preserve the generic --version fallback when Windows metadata/build-directory probes return no version.
Remove the release-owned changelog entry and refresh the branch so it no longer conflicts with base.

Proof guidance:

[P1] Needs real behavior proof before merge: Mock-only: the PR body says the Windows path was exercised by unit tests on macOS, not on a live Windows host; add redacted Windows openclaw doctor terminal output, copied output, screenshot, recording, linked artifact, or logs, then update the PR body or ask for @clawsweeper re-review.

Risk before merge

[P1] The new win32 branch can return null for custom or portable Chromium executables even when the existing generic --version probe would have worked.
[P1] The contributor proof is mock-only; there is still no redacted live Windows openclaw doctor output, terminal screenshot, recording, linked artifact, copied output, or log for this exact patch.
[P1] Two open candidate PRs target the same canonical Windows doctor bug, so maintainers still need to choose one canonical branch or replacement fix.
[P1] GitHub currently reports this PR as conflicting/dirty, so the branch needs a refresh before normal merge review can complete.

Maintainer options:

Preserve the generic fallback before merge (recommended)
Change the Windows path to try the new build-directory and ProductVersion probes first, then fall through to the existing executable --version probe when those signals are unavailable, with a focused regression test.
Accept metadata-only Windows detection
Maintainers may intentionally decide Windows should never use the executable fallback, but that compatibility choice should be explicit before merge.
Choose a canonical candidate branch
If maintainers prefer the sibling PE-metadata branch or a replacement, pause or close the non-canonical branch only after the chosen path has proof and a clean compatibility story.

Next step before merge

[P1] Manual review is needed because live Windows proof, branch conflict resolution, and selection between two open candidate fixes cannot be supplied by an automated repair lane.

Security
Cleared: The diff adds local Windows metadata probing through existing process-execution patterns and does not change dependencies, workflows, lockfiles, secrets, permissions, or publishing surfaces.

Review findings

[P1] Preserve the existing Windows fallback — extensions/browser/src/browser/chrome.executables.ts:749
[P3] Remove the release-owned changelog entry — CHANGELOG.md:10

Review details

Best possible solution:

Land one canonical Browser-plugin fix that reads Windows Chrome metadata or install-layout versions before launching Chrome, preserves the generic fallback, removes release-owned changelog edits, and includes redacted Windows doctor proof.

Do we have a high-confidence way to reproduce the issue?

Yes at source level, but not live in this review: current main warns when readBrowserVersion returns null, matching the linked Windows Chrome 148 report. I did not establish a live Windows reproduction.

Is this the best way to solve the issue?

No, not yet: the owner-local Windows metadata/build-directory direction is plausible, but this patch should preserve the generic fallback, drop the changelog edit, refresh the conflicting branch, and provide real Windows doctor proof.

Full review comments:

[P1] Preserve the existing Windows fallback — extensions/browser/src/browser/chrome.executables.ts:749
Returning directly from readWindowsBrowserVersion means Windows executables with no version directory and no ProductVersion metadata never reach the shipped --version probe. Because readBrowserVersion is exposed through the browser host-inspection facade and custom executable paths exist, fall through when the new reader returns null and cover that path in a test.
Confidence: 0.86
[P3] Remove the release-owned changelog entry — CHANGELOG.md:10
CHANGELOG.md is release-owned in this repository; normal PRs should keep release-note context in the PR body or commit message and let release generation update the changelog. Please drop this entry from the branch.
Confidence: 0.93

Overall correctness: patch is incorrect
Overall confidence: 0.86

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 15de9d881a84.

Label changes

Label justifications:

P2: This is a normal-priority Windows Browser doctor false-positive fix with limited blast radius because the browser tool itself reportedly still works.
merge-risk: 🚨 compatibility: The PR changes Windows behavior in a public browser host-inspection helper and can affect custom or portable Chromium setups that rely on the generic version probe.
rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦪 silver shellfish.
status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: Mock-only: the PR body says the Windows path was exercised by unit tests on macOS, not on a live Windows host; add redacted Windows openclaw doctor terminal output, copied output, screenshot, recording, linked artifact, or logs, then update the PR body or ask for @clawsweeper re-review.

Evidence reviewed

PR surface:

Source +60, Tests +59, Docs +1. Total +120 across 3 files.

View PR surface stats

Area	Files	Added	Net
Source	1	60	+60
Tests	1	59	+59
Docs	1	1	+1
Config	0	0	0
Generated	0	0	0
Other	0	0	0
Total	3	120	+120

What I checked:

Root policy read: Root AGENTS.md was read fully; its proof, compatibility, changelog, and full-surface review guidance affected this PR review. (AGENTS.md:1, 15de9d881a84)
Scoped extension policy read: The touched browser plugin files are under extensions/, so bundled-plugin boundary guidance was read and applied. (extensions/AGENTS.md:1, 15de9d881a84)
Current main still lacks Windows metadata detection: Current main only special-cases macOS bundle metadata before running the executable with --version; there is no Windows build-directory or ProductVersion branch. (extensions/browser/src/browser/chrome.executables.ts:747, 15de9d881a84)
Doctor warning caller matches the reported behavior: Browser doctor calls readVersion(chrome.path), parses the major version, and emits the reported unknown-version warning when the value is missing or unparsable. (extensions/browser/src/doctor-browser.ts:324, 15de9d881a84)
PR bypasses the existing fallback: On the PR head, the win32 branch returns readWindowsBrowserVersion directly, so a Windows executable with no version directory and no ProductVersion metadata never reaches the existing generic --version probe. (extensions/browser/src/browser/chrome.executables.ts:749, f5affd4c7111)
Mock-only Windows coverage: The PR tests stub process.platform and execFileSync and explicitly assert null when both Windows metadata signals are absent; the PR body says no live Windows host was tested. (extensions/browser/src/browser/chrome.version.test.ts:134, f5affd4c7111)

Likely related people:

steipete: Git history shows Peter Steinberger moved browser ownership into the bundled browser plugin and later moved browser runtime seams behind plugin metadata, both central to this version-reader path. (role: browser plugin ownership contributor; confidence: high; commits: 8eeb7f082975, 471d056e2f0d; files: extensions/browser/src/browser/chrome.executables.ts, extensions/browser/src/doctor-browser.ts)
vincentkoc: Release-era history and prior Browser doctor migration work touch the same readiness and version-detection surface. (role: recent area contributor; confidence: medium; commits: 476d948732d0, f374fff3bd39, aa69b12d0086; files: extensions/browser/src/browser/chrome.executables.ts, extensions/browser/src/doctor-browser.ts, src/plugin-sdk/browser-host-inspection.ts)
joshavant: Josh Avant consolidated the browser host-inspection facade that exposes readBrowserVersion outside the immediate doctor caller. (role: adjacent facade owner; confidence: medium; commits: 33ad806a14ef; files: src/plugin-sdk/browser-host-inspection.ts, extensions/browser/browser-host-inspection.ts)
Anmol Ahuja: History shows adjacent work on Windows executable path selection in the same browser executable module. (role: adjacent Windows executable discovery contributor; confidence: low; commits: c40884d306e8; files: extensions/browser/src/browser/chrome.executables.ts)
Dallin Romney: Current blame on the affected lines points to a broad current-main commit, but feature history suggests this is carry-forward rather than the original browser-version design. (role: current-main carry-forward contributor; confidence: low; commits: 18f0eeab20e9; files: extensions/browser/src/browser/chrome.executables.ts, extensions/browser/src/doctor-browser.ts, src/plugin-sdk/browser-host-inspection.ts)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

clawsweeper · 2026-06-27T10:40:32Z

@MukundaKatta thanks for the PR. ClawSweeper is still waiting on real behavior proof before this can move forward.

Useful proof can be a screenshot, short video, terminal output, copied live output, linked artifact, or redacted logs that show the changed behavior after the fix. Please redact private tokens, phone numbers, private endpoints, customer data, and anything else sensitive.

Once proof is added to the PR body or a comment, ClawSweeper or a maintainer can re-check it.

Read PE ProductVersion before a conservative unambiguous install-layout fallback, without interpolating configured paths into PowerShell code.\n\nCo-authored-by: Mukunda Rao Katta <mukunda.vjcs6@gmail.com>

steipete · 2026-07-06T16:48:58Z

Land-ready proof for source head e98cd251d8795716efddd30f54d3b41a232b9a41:

Reworked the Windows path to read the inspected executable's authoritative PE ProductVersion, pass the browser path as a separate PowerShell argument, and invoke the absolute trusted Windows PowerShell path. The install-directory fallback now accepts exactly one version directory and refuses ambiguous update layouts.
Sanitized AWS Crabbox run run_c76c79e38fe7 on lease cbx_e742eae2ef1d: 18/18 focused assertions passed (chrome.version 7, doctor-browser 11) at the exact source head.
Native Azure Windows Server 2022 proof on Crabbox lease cbx_973fa20271d8 (golden-barnacle-89b8), with Node 24.15.0 and Chrome installed from Google's current Enterprise MSI: the five Windows-owned/version-detection assertions passed against Chrome 150.0.7871.47.
Source-blind live harness: direct chrome.exe --version timed out after 10 seconds with zero stdout bytes, while the PR's PE metadata path returned 150.0.7871.47; openclaw doctor --non-interactive reported that exact version and emitted no unknown-version warning.
The same isolated config started a healthy Dev Gateway. A real OpenAI gpt-5.4-mini agent crossed the Gateway WebSocket, invoked Browser tabs against the real Chrome CDP endpoint, grounded WINDOWS_BROWSER_OK in a distinct live URL marker, and persisted the Browser tool call/result in the trajectory. Final harness result: WINDOWS_LIVE_RESULT=PASS.
Fresh autoreview after the absolute-PowerShell hardening: no actionable findings. Current GitHub checks: 65 successful, 30 skipped, 1 neutral, no failures or pending checks.

Known proof detail: the first broad native-Windows test invocation exposed three pre-existing POSIX-only test-fixture assumptions (a macOS Plist path and two /tmp doctor fixtures). The Windows-owned cases and product behavior above pass; those unrelated fixture failures are not hidden or counted as green.

Implementation: extensions/browser/src/browser/chrome.executables.ts:747; regression coverage: extensions/browser/src/browser/chrome.version.test.ts:91.

steipete · 2026-07-06T16:50:38Z

…penclaw#87937) * fix(browser): read Windows Chrome version metadata Read PE ProductVersion before a conservative unambiguous install-layout fallback, without interpolating configured paths into PowerShell code.\n\nCo-authored-by: Mukunda Rao Katta <mukunda.vjcs6@gmail.com> * style(browser): clarify Windows version probe * fix(browser): use trusted Windows PowerShell path --------- Co-authored-by: Peter Steinberger <steipete@gmail.com>

openclaw-barnacle Bot added size: S triage: mock-only-proof Candidate: PR proof only shows tests, mocks, snapshots, lint, typecheck, or CI. labels May 29, 2026

BradGroux mentioned this pull request May 29, 2026

WORKING: All Microsoft Issues and PRs (refresh) #74163

Closed

This was referenced Jun 19, 2026

fix(browser): read Chrome version from PE metadata on Windows #87344

Closed

[Bug]: openclaw doctor reports "Could not determine the installed Chrome version" despite Chrome 148 installed at expected path #87312

Closed

MukundaKatta and others added 3 commits July 6, 2026 11:57

fix(browser): read Windows Chrome version metadata

0cae584

Read PE ProductVersion before a conservative unambiguous install-layout fallback, without interpolating configured paths into PowerShell code.\n\nCo-authored-by: Mukunda Rao Katta <mukunda.vjcs6@gmail.com>

style(browser): clarify Windows version probe

2603181

fix(browser): use trusted Windows PowerShell path

e98cd25

steipete force-pushed the fix/doctor-windows-chrome-version branch from f5affd4 to e98cd25 Compare July 6, 2026 15:58

steipete merged commit 675045f into openclaw:main Jul 6, 2026
96 checks passed

clawsweeper Bot mentioned this pull request Jul 6, 2026

fix(msteams): bound Graph attachment JSON responses #101082

Merged

Sunbelt Computer Software

PL/B Language Development and Support

Navigation Menu

Repository navigation

fix(browser): read Windows Chrome version from build dir in doctor - #87937

fix(browser): read Windows Chrome version from build dir in doctor#87937
steipete merged 3 commits into
openclaw:mainfrom
MukundaKatta:fix/doctor-windows-chrome-version

MukundaKatta commented May 29, 2026

Uh oh!

clawsweeper Bot commented May 29, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented Jun 27, 2026

Uh oh!

steipete commented Jul 6, 2026

Uh oh!

Uh oh!

steipete commented Jul 6, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Sunbelt Computer Software

PL/B Language Development and Support

Conversation

MukundaKatta commented May 29, 2026

Summary

Linked context

Real behavior proof (required for external PRs)

Uh oh!

clawsweeper Bot commented May 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

clawsweeper Bot commented Jun 27, 2026

Uh oh!

steipete commented Jul 6, 2026

Uh oh!

Uh oh!

steipete commented Jul 6, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

clawsweeper Bot commented May 29, 2026 •

edited

Loading