[Enhancement]: SharePoint/OneDrive as a source for persistent knowledge (agent File Search / Project KB), not just per-chat attachments

[simkimsia]

What features would you like to see added?

Today LibreChat has two capabilities that aren't connected:

1. SharePoint/OneDrive file picker ( feat(sharepoint): integrate SharePoint file picker and download workflow #8651) — lets a user browse and select SharePoint/OneDrive files via the Microsoft Graph on-behalf-of (OBO) flow. But selected files are downloaded and attached to a single conversation only (per the SharePoint docs).
2. Agent File Search — semantic RAG over files, but its only source is manual upload, and the knowledge is bound to the agent (persistent, reused across chats).

There is currently no way to use SharePoint/OneDrive as a source for persistent knowledge — i.e. to send picked SharePoint files into an agent's File Search vector store (or the forthcoming standalone Knowledge Base #13494 / Project knowledge #13495) instead of attaching them to a one-off chat.

Request: let users pick SharePoint/OneDrive files (via the existing OBO picker) and ingest them into persistent knowledge — an agent's File Search, and/or a Knowledge Base / Project collection — so the documents are embedded once and reused across every chat that uses that agent/project, without re-attaching per conversation.

Why this is mostly wiring, not a new build: both halves already exist. The picker already downloads SharePoint bytes (OBO); the agent file-upload path already chunks/embeds files into pgvector via rag_api. The new piece is routing a picker-downloaded file into the agent-file / File-Search ingestion endpoint rather than the conversation-attachment endpoint.

Use case

Curated, reusable knowledge from documents that live in SharePoint/OneDrive — e.g. a course's readings, a team handbook, a client reference pack. The user (who already has access to the files) picks them once into an agent's knowledge and chats over them repeatedly. Manual refresh is acceptable for a first version — when a source doc changes, the user re-picks/re-uploads it. Live background sync is explicitly out of scope for v1 (it can come later; see "Future" below).

Proposed scope (v1)

• From the SharePoint/OneDrive picker, allow a target of agent File Search (and/or Knowledge Base / Project knowledge) instead of only the active chat.
• Ingest the OBO-downloaded file through the existing File Search embedding pipeline (chunk → embed → pgvector), reusing current file metadata/flags.
• Treat the result as a snapshot copy (consistent with how uploaded files already behave) — no live link, manual re-pick to refresh.
• Respect the existing agent/KB access model (the ingested copy is governed by who can use the agent/KB, not by the source SharePoint ACL — same as uploaded files today; worth documenting clearly to avoid confusion).

Future / out of scope for v1

• Scheduled re-sync of changed SharePoint files into the knowledge store.
• Source-ACL-aware retrieval (per-user SharePoint permission trimming) — that's a fundamentally different, heavier model and not what this asks for.

Relationship to existing issues

• Builds on feat(sharepoint): integrate SharePoint file picker and download workflow #8651 (SharePoint picker + download workflow).
• Complements Knowledge Base: standalone document collections / RAG (consumable by Projects, agents, and chats) #13494 (standalone Knowledge Base) and Projects: shared context & workspace customization (instructions, knowledge, memory, defaults) #13495 (Project knowledge) by adding SharePoint/OneDrive as an ingestion source — those issues are upload-sourced and don't cover external sources.
• Related to [Enhancement]: Knowledge Base Libraries - Grouped File Management #11204 (Knowledge Base Libraries — reusable collections, closed) and [Enhancement]: File search in specific documents only #10667 (file search in a subset of documents).

Which components are impacted by your request?

File Management, Agents, RAG API / File Search, SharePoint/OneDrive integration, Frontend UI

Pictures

No response

Code of Conduct

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