Feat/Windows Search Index file search#54431
Feat/Windows Search Index file search#54431markguo2016 wants to merge 7 commits intoopenclaw:mainfrom
Conversation
openclaw-barnacle
bot
added
docs
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ba6d07688e
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| const filePrefix = raw.match(/^file:(\/\/\/|\/\/)?/i); | ||
| let rest = raw; | ||
| if (filePrefix) { | ||
| rest = raw.slice(filePrefix[0].length); |
There was a problem hiding this comment.
normalizeWindowsSearchScope strips the file:// prefix and then falls through to the generic path branch for URI-style UNC scopes, so file://server/share/dir becomes file:server/share/dir/ instead of file://server/share/dir/. Because the SQL filter uses SCOPE = '<normalized>', this malformed scope will not match indexed UNC paths and the tool can return no results for valid file: inputs on network shares.
Useful? React with 👍 / 👎.
Greptile SummaryThis PR adds a new Key changes:
Issues found:
Confidence Score: 3/5
Prompt To Fix All With AIThis is a comment left during a code review.
Path: extensions/windows-search/index.ts
Line: 128
Comment:
**ESCAPE clause uses an invalid two-character escape character**
In a PowerShell double-quoted string, `\\` is two literal backslash characters (backslash is not an escape character in PowerShell). The SQL therefore receives `ESCAPE '\\'`, which is the two-character string `\\`. The SQL `LIKE … ESCAPE` clause requires a **single** character — passing two makes the escape character definition undefined/invalid depending on the Windows Search OLE DB provider's behavior.
When the escape character is not correctly defined, `_`, `%`, `[`, and `]` that appear in the search query will be interpreted as LIKE wildcards instead of literal characters. For example, searching for `100%_report` would return far broader results than expected and the escaping work done by `$queryLike.Replace(…)` would be silently bypassed.
The fix is to use a single backslash: `ESCAPE '\'`. In a PowerShell double-quoted string, a bare `\` is already literal — no further escaping is needed.
```suggestion
$whereParts += "System.FileName LIKE '%$queryLike%' ESCAPE '\'"
```
How can I resolve this? If you propose a fix, please make it concise.
---
This is a comment left during a code review.
Path: extensions/windows-search/index.ts
Line: 20-21
Comment:
**Empty query silently matches all indexed files**
`Type.String()` imposes no minimum length, so the framework will accept an empty string for `query`. After trimming and slicing, an empty query produces `$queryLike = ""`, and the generated SQL becomes:
```sql
System.FileName LIKE '%%' ESCAPE '\'
```
This matches every file in the index (or within the specified scope). Combined with the default `limit` of 20 this may be tolerable, but it is undocumented behaviour that could surprise callers and can enumerate a lot of path metadata if `limit` is raised.
Adding `minLength: 1` makes the schema self-documenting and lets the framework reject empty strings before any PowerShell is spawned:
```suggestion
query: Type.String({ description: "Keyword to search for in filenames.", minLength: 1 }),
```
How can I resolve this? If you propose a fix, please make it concise.Reviews (1): Last reviewed commit: "fix(windows-search): escape LIKE and nor..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| $rs = New-Object -ComObject ADODB.Recordset | ||
| $con.Open("Provider=Search.CollatorDSO;Extended Properties='Application=Windows';") | ||
| $whereParts = @() | ||
| $whereParts += "System.FileName LIKE '%$queryLike%' ESCAPE '\\'" |
There was a problem hiding this comment.
In a PowerShell double-quoted string, \\ is two literal backslash characters (backslash is not an escape character in PowerShell). The SQL therefore receives ESCAPE '\\', which is the two-character string \\. The SQL LIKE … ESCAPE clause requires a single character — passing two makes the escape character definition undefined/invalid depending on the Windows Search OLE DB provider's behavior.
When the escape character is not correctly defined, _, %, [, and ] that appear in the search query will be interpreted as LIKE wildcards instead of literal characters. For example, searching for 100%_report would return far broader results than expected and the escaping work done by $queryLike.Replace(…) would be silently bypassed.
The fix is to use a single backslash: ESCAPE '\'. In a PowerShell double-quoted string, a bare \ is already literal — no further escaping is needed.
| $whereParts += "System.FileName LIKE '%$queryLike%' ESCAPE '\\'" | |
| $whereParts += "System.FileName LIKE '%$queryLike%' ESCAPE '\'" |
Prompt To Fix With AI
This is a comment left during a code review.
Path: extensions/windows-search/index.ts
Line: 128
Comment:
**ESCAPE clause uses an invalid two-character escape character**
In a PowerShell double-quoted string, `\\` is two literal backslash characters (backslash is not an escape character in PowerShell). The SQL therefore receives `ESCAPE '\\'`, which is the two-character string `\\`. The SQL `LIKE … ESCAPE` clause requires a **single** character — passing two makes the escape character definition undefined/invalid depending on the Windows Search OLE DB provider's behavior.
When the escape character is not correctly defined, `_`, `%`, `[`, and `]` that appear in the search query will be interpreted as LIKE wildcards instead of literal characters. For example, searching for `100%_report` would return far broader results than expected and the escaping work done by `$queryLike.Replace(…)` would be silently bypassed.
The fix is to use a single backslash: `ESCAPE '\'`. In a PowerShell double-quoted string, a bare `\` is already literal — no further escaping is needed.
```suggestion
$whereParts += "System.FileName LIKE '%$queryLike%' ESCAPE '\'"
```
How can I resolve this? If you propose a fix, please make it concise.
markguo2016
force-pushed
the
fix/windows-search-plugin-loader
branch
from
25c1126 to
be3af41
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: be3af41329
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| const trimmedQuery = String(query ?? "").trim(); | ||
| const boundedQuery = trimmedQuery.slice(0, MAX_QUERY_LEN); |
There was a problem hiding this comment.
When query is empty or whitespace, trimmedQuery becomes "" and the SQL predicate becomes System.FileName LIKE '%%', which matches essentially every indexed file. In that case the tool can return unrelated paths (up to limit) and unintentionally broaden file enumeration instead of doing a keyword search. Add an explicit post-trim guard that returns a validation error when the query is blank.
Useful? React with 👍 / 👎.
markguo2016
force-pushed
the
fix/windows-search-plugin-loader
branch
from
be3af41 to
2bdf2bc
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2bdf2bc0f5
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| const forward = rest.replace(/\\/g, "/"); | ||
| const cleaned = forward.replace(/^\/+/, "").replace(/\/+$/g, "") + "/"; | ||
| return `file:${cleaned}`; |
There was a problem hiding this comment.
Handle forward-slash UNC scopes (//server/share/...) as network authorities instead of generic paths. The UNC matcher only recognizes backslash form, so //... falls through to the fallback branch and is normalized to file:server/share/.../ (missing //). Because the SQL filter uses exact SCOPE = '<normalized>', this malformed scope will not match indexed UNC items (file://server/...) and the tool returns empty results for valid network-share scopes entered with forward slashes.
Useful? React with 👍 / 👎.
- Add plugin config file `openclaw.plugin.json` - Add `package.json` to define plugin dependencies and metadata - Implement core search logic in `index.ts` to quickly locate files via the Windows Search Index - Support search parameters such as filename keywords, extension filters, directory scopes, and time ranges - Handle Windows Search service availability and query errors - Provide standardized error responses and a consistent JSON format for search results
- Add plugin config file `openclaw.plugin.json` - Add `package.json` to define plugin dependencies and metadata - Implement core search logic in `index.ts` to quickly locate files via the Windows Search Index - Support search parameters such as filename keywords, extension filters, directory scopes, and time ranges - Handle Windows Search service availability and query errors - Provide standardized error responses and a consistent JSON format for search results
…xtensions/windows-search 对 openclaw 的 workspace 链接）
markguo2016
force-pushed
the
fix/windows-search-plugin-loader
branch
from
2bdf2bc to
5441c34
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5441c34e0c
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
|
||
| const effective = { | ||
| limit: safeLimit, | ||
| extension: normalizedExtension || undefined, |
There was a problem hiding this comment.
If extension fails extPattern, the SQL filter is dropped because validatedExtension is empty, but effective.extension is still populated from normalizedExtension. That means the tool reports an extension filter that was not actually applied, so callers can trust filtered results when the query was really broadened (for example with ".tar.gz" or other invalid extension strings). Use validatedExtension (or return a validation error) so the reported effective filters match the executed search.
Useful? React with 👍 / 👎.
1 participant
PR: windows-search (Windows Search Index file search)
windows-searchwindows_file_searchextensions/windows-search/openclaw.plugin.jsonextensions/windows-search/package.jsonfor plugin dependencies and metadatawindows_file_searchtool inextensions/windows-search/index.tsto query the native Windows Search Index (Search.CollatorDSO) for fast filename searchesSummary
windows_file_search) backed by the Windows Search Index, with common filters and user-friendly failure messages.Change Type (select all)
Scope (select all touched areas)
Linked Issue/PR
Root Cause / Regression History (if applicable)
N/A
Regression Test Plan (if applicable)
N/A
User-visible / Behavior Changes
windows_file_searchscope,extension,days_ago,limitscopeusesSCOPE = 'file:.../'and normalizes paths:C:\Users\me\Documents→file:C:/Users/me/Documents/\\server\share\dir→file://server/share/dir/Tool Parameters
query(string, required): filename keyword (matchesSystem.FileName LIKE '%query%')limit(number, optional, default 20): max results, clamped to[1, 1000]extension(string, optional):txtor.txt(normalized to.txt)scope(string, optional): folder path orfile:scope; normalized tofile:.../days_ago(number, optional): modified within last N days, clamped to[0, 3650](0 disables the filter)Security Impact (required)
Yes/No) Yes (adds a new search tool)Yes/No) NoYes/No) NoYes/No) Yes (new tool entrypoint)Yes/No) Yes (can enumerate indexed file paths/metadata)Yes, explain risk + mitigation:scope) and time filter (days_ago); does not read file contents.Repro + Verification
Environment
Steps
services.msc, start “Windows Search” (service name:WSearch).{"query":"report"}{"query":"report","scope":"C:\\Users\\me\\Documents","extension":"pdf","days_ago":7,"limit":50}Expected
limitmatching file results quickly, honoringscope/extension/days_agofilters.Actual
Evidence
Human Verification (required)
Review Conversations
Compatibility / Migration
Yes/No) YesYes/No) NoYes/No) NoFailure Recovery (if this breaks)
windows-searchplugin or revert theextensions/windows-searchchangesextensions/windows-search/index.tsextensions/windows-search/openclaw.plugin.jsonextensions/windows-search/package.jsonRisks and Mitigations
scopeto guide users toward indexed locations