"Upload for File Search" Option is missing

[jcbartle]

What happened?

Evening, all.

Reporting a possible code regression related to RAG API integration.

I built a new container image based on the current main branch (as of yesterday, 2025-09-26). This new container image will not integrate with RAG API. The Upload as Text and Upload for File Search menu items are missing from the chat dialog; the only thing present is Upload Image. This occurs with the same exact environment variables and same exact librechat.yaml file. Rolling back to an image built from the codebase as of 2025-09-08 works fine.

The menu items are missing regardless of whether or not interface -> fileSearch is set to true or not in the librechat.yaml file.

The LibreChat logs show:

RAG API is running and reachable at https://<REDACTED>/.

In the RAG API logs, I just get a bunch of these errors, but nothing else:

Unauthorized request with missing or invalid Authorization header to: /

The health check URL reports that the server is up.

Any thoughts?

Version Information

v0.8.0-rc4 (broken)
v0.8.0-rc3 (working)

Steps to Reproduce

1. Leave RAG API alone.
2. Build new Docker image from current codebase.
3. Boot image using same env vars and librechat.yaml file.

What browsers are you seeing the problem on?

Microsoft Edge

Relevant log output

Unauthorized request with missing or invalid Authorization header to: /

Nothing interesting is in the log files or the console logs which I could find.

Screenshots

Code of Conduct

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

[danny-avila]

This is expected, and will have documentation on it over the weekend.

The "Upload for File Search" option only appears now if you toggle "File Search" from the Tools dropdown, which is next to the "Attachment" icon.

You have also likely customized endpoints.agents.capabilities in the librechat.yaml file, and there was a new capability added to enable "Upload as Text" (it is added by default if capabilities are not customized)

# example YAML config
endpoints:
  agents:
    capabilities:
      - "execute_code"
      - "file_search"
      - "actions"
      - "tools"
      - "artifacts"
      - "ocr"
      - "chain"
      - "web_search"
      - "context" # new capability, add this for "Upload as Text"

You will then see the "Upload as Text" option, which no longer requires OCR (but can be enhanced by OCR), as it uses the same text parsing as RAG API along with a fallback method to parse the text:

[paychex-ssmithrand]

@danny-avila Will endpoints.agents in librechat.yml be affected by interface.agents being set to false?

Another thing for us, we don't use Assistants endpoints in our AzureOpenAI deployment. We'd like to use the RAG API as the conduit for file uploads. We previously had success with RAG_USE_FULL_CONTEXT. Will that modify the Upload for File Search behavior?

[danny-avila]

• You can still set endpoints.agents.capabilities with interface.agents set to false
• RAG_USE_FULL_CONTEXT does affect file search behavior but it should be removed soon.

[jcbartle]

@danny-avila - feel free to shoot this down, but, for UI consistency, should the File Search tool get auto-enabled in the conversation when a file which was previously uploaded for RAG is selected and added to the conversation?

[Odrec]

Also it would be nice to have the file search option activated by default for all users.

[harrisonhxy]

so scans, and inserted images arent part of that?

This issue is also bothering me and I would like to get confirmation. Because when I upload files with images as "Upload for Text", my configured openai Embedding model is not called. This seems to be inconsistent with what @danny-avila said*You will then see the "Upload as Text" option, which no longer requires OCR (but can be enhanced by OCR).

So the only explanation so far is that if the file has an image in it, the image will be ignored when uploading it as per "upload for text"?

[gshub77]

@danny-avila thanks. I took this as a prompt to actually set up OCR and found out that mistral on vertex is limited to 30 pages. so it brings an annoying UI question as it shows that “error processing file” without information for the user. so creates uncertainty. not sure what to do, i’ll try without OCR see if that handles large documents better. although that comes around to context windows as we have folks that like to load manuals in an interrogate them