Repomix now fails on repos using backslash in .gitignore patterns

[iki]

Description

Issue Description

When running repomix on repositories that contain .gitignore files with certain backslash-escaped patterns, it fails with error during the file filtering phase.

The underlying path validation (likely from the ignore npm package) throws an error because it encounters a string it doesn't consider a valid relative path.

Steps to Reproduce

You can reproduce this by running Repomix against the following repositories:

Test Case 1: Microsoft Data Formulator

1. Run repomix --remote https://github.com/microsoft/data-formulator
   • Error: Error filtering files: path should be a path.relative()d string, but got "\.\NUL"
   • Failing file: data-formulator/.gitignore

Test Case 2: Claude Code (Best)

1. Run repomix --remote https://github.com/claude-code-best/claude-code
   • Error: Error filtering files: path should be a path.relative()d string, but got "\*.pid.lock"
   • Failing file: claude-code/packages/cloud-artifacts/.gitignore

Solution Discussion

To fix this robustly, we need to look at both the Git specification and how the file-filtering library processes paths.

1. What's the real meaning of a backslash in a .gitignore definition?

According to the official Git documentation:

• A backslash (\) is strictly used as an escape character. It is used to escape characters that would otherwise be treated as special syntax (e.g., \!, \#, \*, \?).
• To ignore a literal backslash, it must be escaped as well (\\).
• Crucially: A backslash is never used as a directory separator in .gitignore, even on Windows. Directory separators are always forward slashes (/).

2. How to handle this best in Repomix?

Currently, it seems Repomix (or its dependency, like ignore) is either incorrectly parsing these escaped rules as file paths, or failing when testing actual files/strings that contain backslashes.

To respect the .gitignore meaning while preventing failing with error, Repomix could implement the following:

• Sanitize Paths Before Validation: Ensure that any string passed to the path-checking/filtering utility is properly normalized to a valid relative path (using forward slashes /).
• Graceful Degradation (Try/Catch): Wrap the file filtering check (e.g., the .ignores() call) in a try...catch block. If a specific path or rule causes the underlying library to throw a path should be a path.relative()d string error, Repomix should log a verbose warning and safely skip that specific file/rule, rather than failing the entire packing process with error.
• Respect Escape Sequences: Ensure the internal globber or gitignore parser isn't accidentally transforming \* or \. into malformed file paths during its traversal phase.

By implementing a fallback/catch for malformed paths, Repomix will become much more resilient to the wild variations of .gitignore files found in the open-source ecosystem.

Usage Context

Repomix CLI

Repomix Version

1.17.0

Node.js Version

v26.5.0

EDIT: Replace AI Agent crash wording. There's no crash, just fail with error. Also fixed links

[nightcityblade]

Hi, I'd like to work on this. I'll submit a PR shortly.

[yamadashy]

@iki Thanks for the report!

I've looked into this but couldn't reproduce the crash in any configuration:

• macOS with v1.17.0, running the exact command above
• Windows CI (Node 22/24/26) with the v1.17.0 dependency set (globby 16.2.1 + ignore 7.0.5)
• Fixtures containing \.\NUL and \*.pid.lock, both with and without a git root

Regression tests: #1775

If you're still hitting this, please share your OS and a full --verbose stack trace.

[iki]

@yamadashy My apologies, there's no crash, just fail with error. I have already replaced some AI agent crash wording when creating the issue, but there were more, so I edited them now.

I already fixed the invalid .gitignore entries in both reproduce cases above (microsoft/data-formulator#406 and claude-code-best/claude-code#1313), however the first one is only merged to dev branch, not yet main, so it's still reproducible. Can you see the error there?

[yamadashy]

@iki You were right — apologies for the earlier "couldn't reproduce"!

The backslash line alone is harmless, but combined with negation (!) rules it takes a different path inside globby, and replaying your data-formulator .gitignore verbatim on Windows CI reproduced the exact error. Root cause is globby 16.2.2's new gitignore pruning; #1775 pins it back to 16.2.1 with regression tests, and I'll report it upstream. Fix ships in the next release.