What happened
isSilentReplyPrefixText guards streamed silent-token prefixes (so a transient "NO" fragment from a streaming NO_REPLY is suppressed). But the character guard rejects any normalized fragment containing characters outside A-Z_:
|
if (normalized.length < 2) { |
|
return false; |
|
} |
|
if (/[^A-Z_]/.test(normalized)) { |
|
return false; |
|
} |
|
const tokenUpper = token.toUpperCase(); |
|
if (!tokenUpper.startsWith(normalized)) { |
|
return false; |
|
} |
|
if (normalized.includes("_")) { |
|
return true; |
|
} |
|
// Keep underscore guard for generic tokens to avoid suppressing unrelated |
|
// uppercase words (e.g. HEART/HE with HEARTBEAT_OK). Only allow bare "NO" |
|
// because NO_REPLY streaming can transiently emit that fragment. |
|
return tokenUpper === SILENT_REPLY_TOKEN && normalized === "NO"; |
if (/[^A-Z_]/.test(normalized)) {
return false;
}So for any custom silent token containing a digit or hyphen (the rest of the tokens API takes an arbitrary token parameter, and comments in the same file explicitly mention custom-token support), streamed prefix fragments like "NOREPLY2"/"NO-ANSWER" prefixes can never match — prefix suppression silently never engages for those tokens, while full-token suppression (isSilentReplyText) does.
Expected
The prefix check should be derived from the configured token's alphabet (e.g. test tokenUpper.startsWith(normalized) against a normalization that permits the token's own characters), not a hard-coded A-Z_ class.
Impact
Deployments using a custom silent-reply token with digits/punctuation get inconsistent behavior: complete tokens are suppressed but streamed prefixes leak to the channel.
Environment
Current main (4287d26).
Found via source review (AI-assisted).
What happened
isSilentReplyPrefixTextguards streamed silent-token prefixes (so a transient"NO"fragment from a streamingNO_REPLYis suppressed). But the character guard rejects any normalized fragment containing characters outsideA-Z_:openclaw/src/auto-reply/tokens.ts
Lines 310 to 326 in 4287d26
So for any custom silent token containing a digit or hyphen (the rest of the tokens API takes an arbitrary
tokenparameter, and comments in the same file explicitly mention custom-token support), streamed prefix fragments like"NOREPLY2"/"NO-ANSWER"prefixes can never match — prefix suppression silently never engages for those tokens, while full-token suppression (isSilentReplyText) does.Expected
The prefix check should be derived from the configured token's alphabet (e.g. test
tokenUpper.startsWith(normalized)against a normalization that permits the token's own characters), not a hard-codedA-Z_class.Impact
Deployments using a custom silent-reply token with digits/punctuation get inconsistent behavior: complete tokens are suppressed but streamed prefixes leak to the channel.
Environment
Current
main(4287d26).Found via source review (AI-assisted).