Greptile Summary

This PR successfully fixes a bug where formatAssistantErrorText's final fallback branch was returning raw, potentially internal error strings (truncated at 600 chars) directly to the user-facing chat surface.

What Changed:

• errors.ts: The final fallback now logs the raw error at warn level (up to 500 chars) for operator debugging and returns a safe, friendly generic message ("Something went wrong. Please try again, or use /new to start a fresh session.")
• formatassistanterrortext.test.ts: Two new unit tests verify unrecognized errors (both realistic orphaned tool_result case and long 800-char strings) return the generic message without leaking raw content
• pi-embedded-subscribe.handlers.lifecycle.test.ts: Two test expectations updated to reflect the generic user message in the error field; the separately-tracked rawErrorPreview (redacted via buildApiErrorObservationFields) remains unchanged

Impact:

• All recognized error patterns (overloaded, rate_limit, context_overflow, etc.) are unchanged
• Only the unrecognized catch-all path is affected
• Raw error text is available to operators in logs for debugging
• Users see a friendly, generic message instead of leaked API internals

Confidence Score: 5/5

• This PR is safe to merge — it's a straightforward bug fix with good test coverage that eliminates information leakage without affecting recognized error handling paths.
• The change is minimal and focused: the final fallback in formatAssistantErrorText now suppresses raw errors from users and returns a safe generic message instead. All recognized error patterns are explicitly untouched. The fix is well-tested with concrete test cases covering realistic orphaned error scenarios and edge cases (long error strings). No comments require action.
• No files require special attention

_{Last reviewed commit: 8469225}

🔒 Aisle Security Analysis

We found 2 potential security issue(s) in this PR:

1. 🟠 Sensitive data exposure in logs due to truncation before redaction in formatAssistantErrorText

Description

formatAssistantErrorText() suppresses unrecognized errors from the user, but logs a preview derived by truncating the raw error before applying redactSensitiveText.

This can leak secrets into logs:

• Input: raw originates from msg.errorMessage (provider/SDK/tooling error strings), which may include credentials (e.g., Bearer ..., API keys, tokens).
• The code truncates: raw.slice(0, 500).
• Redaction is then applied to the truncated string.
• Several default redact patterns require an end word-boundary (e.g., \bBearer ...\b, \b(sk-...)\b). If a token spans across the 500-char boundary, the truncated preview may not match these patterns, leaving a partial (but still sensitive) token unredacted.
• Sink: log.warn(...) writes the preview to log sinks (console/file), resulting in potential credential leakage.

Vulnerable code:

const preview = redactSensitiveText(raw.slice(0, 500)).replace(/[\r\n]+/g, " ");
log.warn(`Unrecognized error suppressed from user surface: ${preview}`);

Why truncation can bypass redaction (examples from default patterns in src/logging/redact.ts):

• \bBearer\s+([A-Za-z0-9._\-+=]{18,})\b
• \b(sk-[A-Za-z0-9_-]{8,})\b

If the token is cut mid-string, the trailing \b may not match, and the token fragment is logged.

Recommendation

Redact before truncation (or truncate with sufficient overlap, then redact, then truncate again) so boundary-dependent patterns still match.

Safer approach (redact full text, then truncate the redacted result):

const redacted = redactSensitiveText(raw).replace(/[\r\n]+/g, " ");
const preview = redacted.length > 500 ? `${redacted.slice(0, 500)}…` : redacted;
log.warn(`Unrecognized error suppressed from user surface: ${preview}`);

If performance is a concern for very large errors, redact a larger slice with overlap, then truncate:

const window = raw.slice(0, 1500); // larger than preview
const redactedWindow = redactSensitiveText(window).replace(/[\r\n]+/g, " ");
const preview = redactedWindow.length > 500 ? `${redactedWindow.slice(0, 500)}…` : redactedWindow;

Optionally, consider fully replacing matched secrets with *** (rather than keeping start/end) for log outputs to reduce residual disclosure risk.

2. 🔵 Terminal/log injection via unsanitized control characters in suppressed error preview log

Description

formatAssistantErrorText() logs a preview of unrecognized raw error text after only redacting secrets and replacing CR/LF. Other control characters (e.g., \t, \u001b / ANSI escape sequences, DEL) can still flow into console logs.

• Input: raw originates from assistant/provider error payloads and can include attacker-influenced content (e.g., upstream service errors, tool output propagated into errors)
• Transformation: redactSensitiveText(...) masks secrets but does not neutralize control characters
• Sink: log.warn(...) ultimately writes to console in pretty/compact styles without stripping ANSI/control chars, enabling terminal escape injection / log obfuscation (CWE-117)

Vulnerable code:

const preview = redactSensitiveText(raw.slice(0, 500)).replace(/[\r\n]+/g, " ");
log.warn(`Unrecognized error suppressed from user surface: ${preview}`);

Recommendation

Sanitize the preview for logs by stripping ANSI escape sequences and all C0 control characters (not just CR/LF) before logging.

This repo already provides sanitizeForLog() in src/terminal/ansi.ts; use it here (or enforce sanitization centrally in the logger):

import { sanitizeForLog } from "../../terminal/ansi.js";

const preview = sanitizeForLog(redactSensitiveText(raw.slice(0, 500)))
  .replace(/\s+/g, " ")
  .trim();
log.warn(`Unrecognized error suppressed from user surface: ${preview}`);

If you want to preserve some whitespace, normalize it (e.g., collapse to single spaces) rather than allowing raw tabs/escapes.

Analyzed PR: #41803 at commit 80307d2

_{Last updated on: 2026-03-22T14:39:45Z}