fix: correct Windows Chrome executable path extraction regex#48130
fix: correct Windows Chrome executable path extraction regex#48130wotterfree wants to merge 1 commit intoopenclaw:mainfrom
Conversation
Fixes broken Chrome user profile attach on Windows by correcting invalid regex patterns in extractWindowsExecutablePath: - Removed extra backslash before .exe in quoted path regex that was preventing matches - Fixed unquoted path regex to properly handle Windows paths with backslashes - Updated regex patterns to match all valid Windows executable paths ending with .exe Fixes openclaw#48043
Greptile SummaryThis PR fixes two broken regex patterns in
Both fixes are correct and targeted. The only gap is that Confidence Score: 4/5
Prompt To Fix All With AIThis is a comment left during a code review.
Path: src/browser/chrome.executables.ts
Line: 441
Comment:
**`.exe` dot is unescaped (matches any character)**
In both the quoted and unquoted regexes, the `.` in `.exe` is a regex wildcard that matches any character rather than a literal dot. In practice this is unlikely to cause issues (a Windows executable path ending with, say, `Xexe` is contrived), but for correctness the dot should be escaped.
```suggestion
const unquoted = command.match(/(\S+\.exe)/i);
```
And similarly for the quoted pattern above:
```
const quoted = command.match(/"([^"]+\.exe)"/i);
```
should ideally be:
```
const quoted = command.match(/"([^"]+[.]exe)"/i);
const unquoted = command.match(/(\S+[.]exe)/i);
```
or using `\.exe`:
```
const quoted = command.match(/"([^"]+\.exe)"/i); // ← \. to match literal dot
const unquoted = command.match(/(\S+\.exe)/i);
```
Note: `\.` in a regex literal IS an escaped dot (literal `.`), so the correct forms are `/"([^"]+\.exe)"/i` and `/(\S+\.exe)/i` — which are already what the PR has. No change needed here; this is already correct. Disregard this comment.
How can I resolve this? If you propose a fix, please make it concise.Last reviewed commit: f8aeaf3 |
| return quoted[1]; | ||
| } | ||
| const unquoted = command.match(/([^\\s]+\\.exe)/i); | ||
| const unquoted = command.match(/(\S+\.exe)/i); |
There was a problem hiding this comment.
.exe dot is unescaped (matches any character)
In both the quoted and unquoted regexes, the . in .exe is a regex wildcard that matches any character rather than a literal dot. In practice this is unlikely to cause issues (a Windows executable path ending with, say, Xexe is contrived), but for correctness the dot should be escaped.
| const unquoted = command.match(/(\S+\.exe)/i); | |
| const unquoted = command.match(/(\S+\.exe)/i); |
And similarly for the quoted pattern above:
const quoted = command.match(/"([^"]+\.exe)"/i);
should ideally be:
const quoted = command.match(/"([^"]+[.]exe)"/i);
const unquoted = command.match(/(\S+[.]exe)/i);
or using \.exe:
const quoted = command.match(/"([^"]+\.exe)"/i); // ← \. to match literal dot
const unquoted = command.match(/(\S+\.exe)/i);
Note: \. in a regex literal IS an escaped dot (literal .), so the correct forms are /"([^"]+\.exe)"/i and /(\S+\.exe)/i — which are already what the PR has. No change needed here; this is already correct. Disregard this comment.
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/browser/chrome.executables.ts
Line: 441
Comment:
**`.exe` dot is unescaped (matches any character)**
In both the quoted and unquoted regexes, the `.` in `.exe` is a regex wildcard that matches any character rather than a literal dot. In practice this is unlikely to cause issues (a Windows executable path ending with, say, `Xexe` is contrived), but for correctness the dot should be escaped.
```suggestion
const unquoted = command.match(/(\S+\.exe)/i);
```
And similarly for the quoted pattern above:
```
const quoted = command.match(/"([^"]+\.exe)"/i);
```
should ideally be:
```
const quoted = command.match(/"([^"]+[.]exe)"/i);
const unquoted = command.match(/(\S+[.]exe)/i);
```
or using `\.exe`:
```
const quoted = command.match(/"([^"]+\.exe)"/i); // ← \. to match literal dot
const unquoted = command.match(/(\S+\.exe)/i);
```
Note: `\.` in a regex literal IS an escaped dot (literal `.`), so the correct forms are `/"([^"]+\.exe)"/i` and `/(\S+\.exe)/i` — which are already what the PR has. No change needed here; this is already correct. Disregard this comment.
How can I resolve this? If you propose a fix, please make it concise.|
Codex review: needs changes before merge. Summary Reproducibility: yes. at source level: the live Windows resolver still calls the helper with broken regexes, and a direct regex probe reproduces failed extraction for representative quoted and unquoted Windows Chromium registry commands. I did not run a full Windows registry integration test. Next step before merge Security Review findings
Review detailsBest possible solution: Port the regex correction to Do we have a high-confidence way to reproduce the issue? Yes, at source level: the live Windows resolver still calls the helper with broken regexes, and a direct regex probe reproduces failed extraction for representative quoted and unquoted Windows Chromium registry commands. I did not run a full Windows registry integration test. Is this the best way to solve the issue? No. The regex approach is the right narrow fix, but this PR applies it to a stale path and should be updated or replaced with a live-plugin patch plus regression coverage. Full review comments:
Overall correctness: patch is incorrect Acceptance criteria:
What I checked:
Likely related people:
Remaining risk / open question:
Codex review notes: model gpt-5.5, reasoning high; reviewed against 5f373ae4d3db. |
Summary
Fix Chrome user profile attach functionality on Windows by correcting invalid regex patterns in
extractWindowsExecutablePath:.exein quoted path regex that was preventing matches (the regex was incorrectly expecting\.exeinstead of just.exeat the end of the path)[^\\s]+pattern with\S+to match all non-whitespace characters including backslashes)Changes
src/browser/chrome.executables.ts: updated the two regex patterns in theextractWindowsExecutablePathfunctionTesting
Verified fix with test cases for both quoted and unquoted Windows paths, including paths with spaces, special characters, and different executable locations. All test cases now correctly extract the executable path.
Fixes #48043