I enabled the large language model's memory function, but I found that it didn't remember my input or the links to the files I uploaded

[linyuanchun]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

I enabled the large language model's memory function, but I found that it didn't remember my input or the links to the files I uploaded. What should I do?

2. Additional context or comments

No response

[dosubot[bot]]

Dify's memory function has some known limitations and configuration requirements that can cause it not to retain user inputs or uploaded file links. Here are the main things to check and try:

• If your memory mode is set to last_user_message, only the most recent user message is kept—previous history and file links are discarded. For workflows that need more context, use a different memory mode or increase the memory window size if possible (source).
• For file uploads: if you upload images but your model is not multimodal, memory retention will break or cause errors. Stick to text-based documents (PDF, DOCX, TXT), or preprocess images with OCR before uploading. If you need to support images, use a multimodal model (source).
• If you see errors like User message content must be str after uploading files, move your system prompts into user prompts in your workflow configuration. Some models do not support system prompts with memory enabled and file uploads (source).
• If you are using the Chatflow agent node and memory fails with documents, try switching to the LLM node, which handles memory more reliably in some cases (source).
• Make sure your workflow node is actually configured with a memory window and that your app has enough resources (memory, threads) to store and retrieve conversation history.
• If you are on an older version (e.g., 1.4.0), there were bugs with memory and file uploads that have since been fixed. Updating to the latest version may resolve the issue (source).

If you need to store processed or rewritten inputs in memory (not just the original user input), Dify does not support this out of the box—you would need a custom solution or external conversation history management (source).

If you have specific error logs or details about your workflow setup, I can help you debug further.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[linyuanchun]

{
role: "user",
text: "what is that",
files: [
{
type: "image",
data: "data:image...[TRUNCATED]...5ErkJggg==",
detail: "high"
}
]
},I found that the built-in memory data transfer works like this: no file links are preserved.

[dosubot[bot]]

What you're seeing is a known limitation in how Dify handles memory for file uploads, especially images. When you upload an image, Dify's memory system does not store a persistent file link in the conversation history. Instead, it either embeds the raw image data (as base64, which can cause memory bloat) or, in some cases, just inserts a placeholder like [image]—so file links are not preserved or shown in the memory context you see or transfer between turns. This is by design in the current implementation and affects multi-turn workflows and memory exports as well source.

If you want Dify to store image references as URLs (instead of base64), you can set MULTIMODAL_SEND_FORMAT=url in your .env file and configure FILES_URL to point to an externally accessible address, but this only works if your LLM and deployment support URL-based image access source. If that's not possible, you can patch the code to store only a summary or metadata string for images in memory, instead of the full image data source.

This behavior also means Dify doesn't support file management or persistent file links in memory out of the box, so uploaded files must be processed immediately and can't be reliably referenced in later turns or exported memory source.

If you need more details or want a step-by-step workaround, let me know your Dify version and workflow setup.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[linyuanchun]

How to input specified content into the memory?

[dosubot[bot]]

Dify does not provide a built-in way to directly inject arbitrary content into the LLM memory context. Memory is automatically built from user messages, system prompts, and file uploads as processed by the workflow. If you want to input specified content into memory, here are your main options:

• In a workflow, you can use variables, context, or a Code node to prepare the content you want the LLM to "remember." Then, reference these variables in your LLM node's prompt template or context field. This doesn't persist the content in memory across turns, but it does inject it into the prompt for the current turn, which is often enough for most use cases. For example, you can set a variable with your custom content and use Jinja2 templating in your prompt: {{ my_variable }} will be replaced with your content when the prompt is rendered. This is the recommended approach for most users and does not require code changes source.

• If you need the content to persist across turns (true "memory"), you would need to insert it into the conversation history. This requires either (a) using a Code node to create a synthetic user message and saving it to the conversation, or (b) modifying the backend code (e.g., TokenBufferMemory or the Message table) to append your custom content to the memory before it is sent to the LLM. This is an advanced approach and not supported out-of-the-box source.

• For file links or file content, Dify's memory system does not preserve file links in conversation history. If you need to reference files, store their metadata or URLs in a variable and inject that variable into the prompt as described above source.

• For advanced or persistent memory needs, consider using session variables, external storage, or a retrieval-augmented generation (RAG) approach to manage and inject relevant content into the prompt at runtime source.

There is a planned "memory variables" feature for more flexible memory management, but it is not yet generally available source.

If you need a code-level example or more details for your specific workflow, let me know your use case and whether you want a UI-based or code-based solution.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}