Search: Path:"…*" prefix restriction returns 0 results when the quoted prefix contains "(" or ")" #11034

Summary

A Path-restricted KQL query of the form Path:"<literal prefix>*" (trailing-wildcard prefix match — the standard way to scope a search to one document library folder) returns zero results whenever the literal prefix contains a ( or ) character anywhere, even though the prefix is a verified-correct literal prefix of the real indexed Path value. Other punctuation in the same prefix (commas, hyphens) causes no problem. Backslash-escaping the parentheses makes no difference. This does not appear to be documented anywhere we could find.

Environment

• SharePoint Online (Microsoft 365, tested against a live production tenant, September 2026)
• Query executed via CSOM (Microsoft.SharePoint.Client.Search.Query.KeywordQuery / SearchExecutor), package Microsoft.SharePointOnline.CSOM 16.1.27011.12008
• The same pattern (failing on (/), working once truncated before it) was also observed earlier via the tenant's own web search box, pasting the equivalent query text directly — a separate, less controlled round of testing than the CSOM results below, but consistent with them

Repro

Real folder path (redacted tenant, structure preserved):

https://<tenant>.sharepoint.com/sites/<site>/<library>/<client folder>/<matter folder> (Decd)

Confirmed via the Search REST API (_api/search/query?...&selectproperties='Path') that the indexed Path value for an item under this folder is exactly, character-for-character, the string above (compared programmatically, ordinal character codes, plain ASCII — no hidden/smart-quote characters).

Queries that fail (0 results, including with no free-text search term at all)

Path:"https://<tenant>.sharepoint.com/sites/<site>/<library>/<client folder>/<matter folder> (Decd)*"

<searchterm> Path:"https://<tenant>.sharepoint.com/sites/<site>/<library>/<client folder>/<matter folder> (Decd)*"

Also fails identically with the parentheses preceded by a backslash (KQL defines no escape mechanism for quoted phrases, so this was tried only for completeness — still 0 results):

<searchterm> Path:"https://<tenant>.sharepoint.com/sites/<site>/<library>/<client folder>/<matter folder> \(Decd\)*"

Also fails with only the trailing ) trimmed, so the wildcard now immediately follows a letter rather than punctuation (ruling out "the wildcard specifically must follow a word character" as the explanation):

<searchterm> Path:"https://<tenant>.sharepoint.com/sites/<site>/<library>/<client folder>/<matter folder> (Decd*"

Query that succeeds (128 results)

Truncating the prefix to end before the parenthesis entirely:

<searchterm> Path:"https://<tenant>.sharepoint.com/sites/<site>/<library>/<client folder>/<matter folder>*"

Server-reported total match count (ResultTable.TotalRows) equals the 128 rows actually returned (RowLimit was 1000, so this isn't a row-limit artifact), and the results include items whose full Path is under the parenthesised folder itself (e.g. .../<matter folder> (Decd)/Documents/...) — i.e. the content that the failing, more specific query above should have found, and didn't.

Control: other punctuation in the same prefix is unaffected

The succeeding query's prefix contains a comma and multiple hyphens (<client folder> contains , and the matter folder contains multiple - separators plus a numeric ID with an embedded hyphen), and matches correctly. So this isn't a general punctuation/reserved-character problem — it's specific to (/).

Reproduced on 4 independent real folders

In every failing case, truncating the Path:"...*" prefix to end immediately before the first ( restores correct, complete results.

Expected behavior

Per the formal KQL protocol grammar, [MS-KQL] §2 Structures and §2.3.1 String Tokens:

quoted-string-value = DQUOTE 1*(%x00-21 / DQUOTE DQUOTE / %x23-ffffffff) DQUOTE

[A double quotation mark within the quoted string MUST be represented by two double quotation marks.] Any Unicode character is allowed [inside a quoted-string-value]... An unquoted-string-value ... cannot contain white space characters, double quotes, or parentheses.

Parentheses are explicitly reserved only in the unquoted form; the quoted form explicitly permits any character. Our Path value is quoted. §2.3.1.2 String Token Prefix also confirms wildcard evaluation is supported for quoted-string-value, and the public KQL syntax reference gives the documented form title:"Advanced Sear*" for exactly this trailing-wildcard-on-a-quoted-phrase pattern. So a trailing-wildcard match against a verified-correct literal prefix of the indexed data should match.

(Separately: the parentheses here are inside the quoted value, not the documented Property:(<expression>) grouping syntax, so that isn't a relevant distinction either.)

Unverified hypothesis, not asserted as fact: Path may use "Complete Matching" (NoWordBreaker) rather than being word-broken like a typical text property, which would make this a literal whole-string prefix match rather than a token match. We have not confirmed this via the tenant's Search Schema configuration, and could not find Microsoft documentation stating it either way — flagging only as our leading theory for why the property might behave differently from ordinary text search, not as an established fact.

Actual behavior

Zero results, specifically and only when the prefix (up to the wildcard) contains ( or ), regardless of:

• whether the parenthesis is at the end, mid-string, or preceded/followed by other characters
• whether it's preceded by a backslash
• whether a free-text search term is combined with the Path: restriction or the Path: restriction is used alone

Workaround in use

Truncate the query prefix at the first ( before appending the trailing wildcard. This broadens the search scope beyond the exact intended folder, but in every case tested it stayed correctly scoped, since the part of the path that makes it unique always appeared before the first parenthesis.

Question for Microsoft

Is this documented behavior of the Path managed property that we've been unable to find documentation for? Or is this a bug in how the search index or query engine handles (/) for this property? A pointer to relevant documentation, or confirmation this is a bug, would be appreciated.