[Bug]: Local file deletion fails on Windows (path.sep vs POSIX paths in crud.js)

[SwDevOp72]

What happened?

On Windows with the local file storage strategy, deleting any image file stored under /images// fails with a TypeError. Uploaded images, generated images and agent avatars can therefore never be deleted; the file and its DB record remain.

Cause: api/server/services/Files/Local/crud.js stores file paths with path.posix.join (forward slashes, line 95) but splits them again with path.sep when deleting (lines 258-259). On Windows path.sep is a backslash, so the split yields a single element, subfolder is undefined, and isValidPath(req, publicPath, undefined, filepath) calls path.resolve(base, undefined, ...) which throws "The paths[1] argument must be of type string" (line 201). Files under /uploads// are unaffected because that branch returns earlier.

The call chain is the normal UI deletion path: routes/files/files.js:277 -> processDeleteRequest (services/Files/process.js:325) -> deleteLocalFile (crud.js:266) -> isValidPath (crud.js:201).

Side effect: the client keeps failed deletions in localStorage (FILES_TO_DELETE) and retries them on every mount of the chat view (client/src/components/Chat/Presentation.tsx:81-100), so the error log fills with one DELETE /api/files per minute while a user has such files pending.

On Linux path.sep is "/", so the bug never shows there.

Suggested fix: split on "/" instead of path.sep in crud.js:258, consistent with how the same file builds the path. No behaviour change on Linux.

Our instance: 137 file records, 65 of them images under /images/ that cannot be deleted; 96 failed DELETE /api/files requests from a single session within 72 minutes.

Version Information

LibreChat v0.8.8-rc3, Windows Server (native, no Docker), fileStrategy: local. The code is unchanged in v0.8.8-rc4 (crud.js:269-270).

Steps to Reproduce

1. Run LibreChat natively on Windows with the local file strategy.
2. Upload an image in a chat or set an agent avatar.
3. Delete the image (or the conversation) in the UI.
4. Observe in the error log: DELETE /api/files fails with "The paths[1] argument must be of type string" at services/Files/Local/crud.js:201; the file and DB record remain.
5. Reload the chat view: the DELETE is retried and fails again.

What browsers are you seeing the problem on?

Microsoft Edge

Relevant log output

{
  "code": "ERR_INVALID_ARG_TYPE",
  "level": "error",
  "message": "The \"paths[1]\" argument must be of type string. Received undefined",
  "name": "TypeError",
  "requestId": "<requestId>",
  "request_id": "<requestId>",
  "request_method": "DELETE",
  "request_path": "/api/files",
  "stack": "TypeError [ERR_INVALID_ARG_TYPE]: The \"paths[1]\" argument must be of type string. Received undefined\n    at isValidPath (api/server/services/Files/Local/crud.js:201:31)\n    at deleteLocalFile (api/server/services/Files/Local/crud.js:266:8)\n    at async api/server/services/Files/process.js:205:7\n    at async processDeleteRequest (api/server/services/Files/process.js:325:3)\n    at async api/server/routes/files/files.js:277:22",
  "timestamp": "2026-09-23T23:51:16.560Z",
  "userId": "<userId>"
}

Screenshots

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[Harshul1484]

I'd like to take this. The plan is to split the stored path on / in deleteLocalFile (crud.js:269), matching the path.posix.join that builds it, with a regression test for deleting a file under /images/<userId>/ using Windows path semantics.

[theworker02]

Taking this — splitting stored POSIX paths on / in deleteLocalFile (matching path.posix.join) so Windows path.sep no longer breaks image deletion. Opening a PR shortly.

[mehran-almma]

I checked this against current dev on native Windows 11, along with #16399.

Reproduced. On dev, deleting /images/<userId>/a.png through deleteLocalFile fails with The "paths[1]" argument must be of type string, as reported. crud.js:269 still reads cleanFilepath.split(path.sep).

#16399's fix is correct, but its test won't catch this bug if it comes back. CI runs on Linux, where path.sep === '/', so the new spec also passes without the fix. I ran the same test case with path.sep mocked each way:

code	sep = '/' (CI)	sep = '\\' (Windows)
dev (unpatched)	pass	fail (paths[1] TypeError)
#16399	pass	pass

If the spec fixes the separator, it fails on unpatched code on any OS:

jest.mock('path', () => ({ ...jest.requireActual('path'), sep: '\\' }));

jest.mock applies to the whole file, so this belongs in its own spec file (or behind jest.isolateModules). Otherwise the other crud-delete cases also run with a Windows separator.

Two smaller points:

• Even after the fix, a stored path with no / (for example a bare foo.png that isn't under agents) still leaves subfolder undefined. It then throws the raw TypeError instead of Invalid file path. A if (!subfolder) throw new Error('Invalid file path') after the agents early return would make that failure predictable.
• Existing instances need no data migration. The stored paths are already correct POSIX paths; only the delete code was reading them wrongly. After the patch, the stuck images can be deleted again. The client's FILES_TO_DELETE queue clears its temp-file entries once the DELETE succeeds, so the retry-every-minute log noise stops by itself.