Bug: truncateBase64 causes false positives on 60+ char XPath / path-like strings

[NaustudentX14]

Description

Description:
When truncateBase64: true is enabled, the internal regex aggressively matches normal application strings (like file paths or XPaths) that contain a mix of letters and forward slashes, assuming they are standalone Base64 data.

For example, I had the following XPath string in a Python file:
".//postTransactionAmounts/sharesOwnedFollowingTransaction/value"

Repomix silently truncated this in the output XML to:
".//postTransactionAmounts/sharesO..."

Root Cause:
Looking at src/core/file/truncateBase64.ts, the issue is a mathematical coincidence with the current constants:

const MIN_BASE64_LENGTH_STANDALONE = 60;
const TRUNCATION_LENGTH = 32;
const MIN_CHAR_TYPE_COUNT = 3;

The string inside the quotes, postTransactionAmounts/sharesOwnedFollowingTransaction/value, happens to be exactly 60 characters long.

Because it hits the 60 character minimum, it gets tested by isLikelyBase64(). It passes the validation because it has:

1. Uppercase letters
2. Lowercase letters
3. Special characters (the / slashes)

This satisfies MIN_CHAR_TYPE_COUNT = 3. As a result, the tool mistakenly identifies the XPath as Base64 and truncates it to 32 characters.

Proposed Solutions:

1. Increase the standalone length threshold (Recommended)
Truncating a 60-character string to 32 characters only saves a handful of tokens, which defeats the purpose of the feature (which is meant to catch massive embedded files). Bumping the minimum length significantly would stop false positives on standard code strings:

// In src/core/file/truncateBase64.ts
const MIN_BASE64_LENGTH_STANDALONE = 256; // or 512

2. Improve the isLikelyBase64 heuristic
Real Base64 encoded data almost always contains numbers and mixes + and / randomly. The validation function could reject strings that look like file paths/XPaths (e.g., they contain / but lack numbers or + signs):

function isLikelyBase64(str: string): boolean {
  // ... existing checks ...
  const hasNumbers = /[0-9]/.test(str);
  
  // Reject strings that look like paths/XPaths
  if (str.includes('/') && !str.includes('+') && !hasNumbers) {
    return false;
  }
  // ...
}

Workaround:
Setting truncateBase64: false in repomix.config.js resolves the issue and leaves the string intact.

Usage Context

Repomix CLI

Repomix Version

1.13.0

Node.js Version

v24.14.0

[yamadashy]

Hi, @NaustudentX14 !

Thank you for the excellent bug report!
Your analysis of the root cause and proposed solutions made this very easy to fix.

This has been addressed in #1307 with both of your suggested approaches:

1. Raised MIN_BASE64_LENGTH_STANDALONE from 60 to 256
2. Added a digits requirement to the isLikelyBase64 heuristic

The fix will be included in the next release.

[JiwaniZakir]

The false positive stems from isLikelyBase64() in src/core/file/truncateBase64.ts using character-type diversity as a proxy for Base64 entropy, which breaks down for path-like strings that naturally contain mixed case and / delimiters. The core issue is that the MIN_CHAR_TYPE_COUNT = 3 check conflates structural characters (path separators) with the random character distribution that actually characterizes Base64 data. Beyond raising MIN_BASE64_LENGTH_STANDALONE, a stronger heuristic would be to require the presence of digits — real Base64 payloads of any meaningful length almost always contain numeric characters, whereas XPath and file path strings frequently do not. Alternatively, checking that / appears at a frequency consistent with Base64 padding noise (rather than as a repeating structural delimiter) would also significantly reduce false positives without needing to touch the length threshold.