[Enhancement]: Add option to disable "Upload to Provider"

[marpro200]

What features would you like to see added?

Hey I would like to be able to disable the "Upload to Provider" option.

More details

Our company works with internal documents and therefore we are using the rag api. To avoid that people upload sensitive information to the providers, I would like to disable that option.

Which components are impacted by your request?

UI

Pictures

No response

Code of Conduct

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

[dominicfallows]

I'm working on an option for this for our use case, but intending to submit to upstream: #11279

[danmwallace]

Just wanted to bump this, I think it's a great idea to have this parameter. Looking forward to having it added, currently stuck and can't update due to a newer release as a result.

[quarker1337]

Having the same issue. Need granularity not just for company-privacy but also for Models/APIs which dont support File Upload at all and fill just run into unknown errors when trying it.

[marpro200]

@dominicfallows Hey did you manage to create a fix for this?

[crp4222]

An alternative to disabling uploads: a PII proxy that strips sensitive data from all traffic before it reaches the provider. Users keep full functionality, but nothing identifiable leaves your infra: https://github.com/crp4222/PrivAiTe

[SwDevOp72]

Swiss NPO here, same issue for us. We therefore also stronly support this enhancement.

We must be able to prevent users from loading up sensitive data directly to providers. If user chooses Upload as Text, our own PII proxy can sanitize it, but not for documents.

We can hard-block any block content in our PII Proxy, thats the hard way, but it would make perfect sense to be able to disable that psossibility in the chat GUI too.

[azroberts8]

Any updates here? I'm in the same situation as @quarker1337. My API doesn't support file uploads and users are getting confused when the "upload to provider" option doesn't work so I'd like to disable it or hide it from the UI entirely.

[thekk1]

Adding a concrete use case, plus reproduction data for the failure mode this option causes. (#13334 covers the underlying bug but is no longer open for comments, so I'm putting the evidence here.)

Setup

• LibreChat v0.8.7 (stable image, ghcr.io/danny-avila/librechat:latest)
• Custom endpoint pointing at a self-hosted llama.cpp server, b10239-f2b52a87e, OpenAI-compatible /v1
• Agent with an MCP server attached

Why we want this option

For us "Upload to Provider" is not merely unnecessary — it is a trap. An OpenAI-compatible backend without native document support cannot process the file content block. Every attempt fails with:

error: [api/server/controllers/agents/client.js #sendCompletion] Unhandled error type 400 unsupported content[].type

And in the UI: An error occurred while processing the request: 400 unsupported content[].type

Worse, the failure is not transient. As analysed in #13334, the error is persisted into contentParts and re-sent with every subsequent request, so the conversation is permanently unusable and has to be deleted. We hit this four times before understanding why.

"Upload as Text" works correctly against the same backend and is what we want our users to use. But there is no way to steer them there, because both options appear side by side and nothing indicates that one of them cannot work.

Configuration-side mitigations we tried, none of which work

• fileConfig.endpoints.<endpointName>.disabled: true — disables all uploads for the endpoint, including "Upload as Text". Documented as "prevents any file uploads to the specified endpoint, overriding any other file-related settings", so this is expected, just not usable.
• Restricting supportedMimeTypes — no effect on this path: the "Upload to Provider" picker uses a hardcoded type list rather than the configured patterns ([Bug]: Upload to provider fails silently for file types not included in hardcoded list of allowed types #12482, [Bug]: Allowed file types in Upload file popup does not match provider's allowed types #12589).
• interface.fileSearch: false — only affects the RAG path.

Suggested shape

A per-endpoint flag would solve it directly:

fileConfig:
  endpoints:
    MyCustomEndpoint:
      providerUpload: false

A capability-derived alternative would be better still: AttachFileMenu.tsx and AttachFileChat.tsx currently don't check whether the resolved provider supports document blocks, and formatAssistantMessage() has no file case, so the block passes through unfiltered. Offering the option only where the provider declares support would make the config flag unnecessary and would also address #13334.

Either way, an admin-side switch would be valuable for deployments like ours — self-hosted, single backend, where we know in advance that the option can never succeed.

[privat655]

Any solution to this yet? We are trapped with OpenAI only becouse our users want to be able to upload pdfs and get errors otherwise.
It would be great to be able to turn "Upload to Provider" off for the endpoints / agents that do not support it.

[SwDevOp72]

I agree with @privat655 that this would be an important feature we've been hoping for some time now.

[lia-by-librechat]

Closing this as resolved by the unified file upload work on dev.

Two things changed since this was filed:

1. The "Upload to Provider" item no longer renders by default. The destination chooser is now legacy-only. In AttachFileMenu.tsx unified mode returns early and renders upload sources (local machine, SharePoint), not destinations; the menu holding com_ui_upload_provider is only reached when an endpoint opts back in with legacyFileUploadUX: true. Unified is the default, since isUnifiedUploadMode is legacyFileUploadUX !== true and that key defaults to unset.

2. Routing is now an admin setting enforced on the server, which is closer to what you actually asked for: hiding a menu item is cosmetic, this is not. fileConfig gained defaultLLMDeliveryPath, a { fallback, overrides } object over provider | text | none, settable globally or per endpoint. Precedence is endpoint overrides, endpoint fallback, global overrides, global fallback, then system defaults. Admin config short-circuits ahead of the capability gating, so it wins.

To keep every upload off provider file APIs regardless of what a user clicks:

fileConfig:
  defaultLLMDeliveryPath:
    fallback: none
    overrides:
      'image/*': none
      'audio/*': none
      'video/*': none
      'application/pdf': none

Use text instead of none for the types you want extracted locally (RAG/OCR) and summarized into the prompt; none stores the file and leaves it reachable by tools without putting it on the model path. Enforcement is in Files/process.js and the upload router, not in the client, so a user cannot override it.

Related: #15763 introduced all of the above; follow-ups #15937, #15940 and #15946 refined custom endpoint media, the opt-in text fallback, and extracted-text preview.