Why OpenHuman Memory Trees Show 0 buffer(s): A Complete Troubleshooting Guide from Vault Sync to Summary Tree
❝
「Core question this article answers:」 Why does OpenHuman show
Building summary trees · 0 buffer(s)even after files have synced successfully?❞
Here is the short answer:
「If you only added a local Vault (such as Markdown or TXT files), OpenHuman may show synced successfully but still fail to build a memory tree. In the observed workflow, Summary Trees only work with supported data sources like Gmail, Slack, and Notion. Local Vault files sync successfully, but they do not automatically enter the memory pipeline that powers Summary Trees.」
This article walks through the entire troubleshooting journey—from suspecting file path errors and embedding configuration issues, to analyzing logs, debugging workers, and finally identifying the actual product behavior.
The conclusion matters, but the troubleshooting process matters even more.
Understanding OpenHuman Memory: What Is It Actually Doing?
❝
「Core question:」 What does OpenHuman “memory” really mean, and how is it different from chat history?
❞
Many people first approach OpenHuman with a simple assumption:
❝
“It remembers everything.”
❞
In practice, that assumption quickly breaks.
OpenHuman behaves less like an infinite chat archive and more like a 「structured long-term context system」.
Inside the interface, several concepts immediately stand out:
-
Vault -
Sync -
Summary Tree -
Tree View -
Storage
These labels naturally create an expectation:
❝
“If I add my files, the system will understand my knowledge base.”
❞
That assumption turns out to be misleading.
Based strictly on the observed behavior during testing, OpenHuman appears closer to:
❝
「A personal digital context system」
❞
Its memory model seems designed around extracting structured signals from services such as:
-
Gmail -
Slack -
Notion
Rather than treating local files as a fully searchable personal knowledge graph.
The distinction matters because it explains nearly every confusing symptom later in the troubleshooting process.
The Problem: Why Does the Summary Tree Stay Empty?
❝
「Core question:」 Why does OpenHuman fail to build a memory tree even after file synchronization succeeds?
❞
The issue surfaced quickly.
A local Vault was added:
F:\12
Initially, the interface showed:
0 file(s)
At this point, several explanations seemed reasonable:
-
Incorrect path? -
Permission issue? -
Unsupported file format? -
Sync failure?
After adding test files into the folder, the status changed:
3 file(s) · synced 1m ago
Naturally, the next expectation was:
❝
“Sync succeeded, now the Summary Tree should build.”
❞
But clicking 「Build Summary Tree」 produced something unexpected:
Building summary trees · 0 buffer(s)
Force-sealing every L0 buffer through the configured AI summariser. The graph will refresh once the worker drains.
This created the core contradiction:
❝
「How can there be 3 synced files but 0 buffers?」
❞
That contradiction drove the entire investigation.
First Wrong Assumption: The File Path Must Be Broken
❝
「Core question:」 Is
\\?\F:\12a path error?❞
At some point, the Vault path changed from:
F:\12
to:
\\?\F:\12
That immediately looked suspicious.
The first instinct was:
❝
“Why is there a question mark in the path?”
❞
It felt like corruption or misconfiguration.
But after closer examination, this turned out to be normal Windows behavior.
For example:
Regular path:
F:\12
Internal system path:
\\?\F:\12
This is Windows extended-length path formatting.
Its purpose is straightforward:
❝
Access the path exactly as written, without additional parsing.
❞
In other words:
❝
「The path was not broken.」
❞
More importantly, the system already showed:
3 file(s) · synced
That confirmed something critical:
❝
OpenHuman was successfully reading files from the Vault.
❞
The path theory no longer held up.
Second Wrong Assumption: Missing Embeddings or AI Models
❝
「Core question:」 Is the Summary Tree failing because embeddings are not configured?
❞
The next theory felt even more plausible.
Since the interface showed:
0 buffer(s)
it seemed reasonable to suspect:
-
Missing embedding provider -
Missing summarizer model -
API key configuration issue -
Local inference disabled
This assumption became even stronger because the interface referenced:
AI summariser
The troubleshooting process shifted toward model configuration.
Possible suspects included:
-
OpenAI API keys -
Embedding models -
Local inference -
Ollama -
Summary providers
At first glance, this felt like the obvious answer.
After all:
❝
Building memory sounds like something that requires AI models.
❞
But reality turned out to be more complicated.
Reading the Logs: What Was Actually Happening?
❝
「Core question:」 What did the logs reveal?
❞
System logs became the next source of truth.
One important line stood out:
[memory:ingestion_queue] background worker started
This suggested:
❝
The ingestion worker was running correctly.
❞
Additional logs appeared healthy as well:
openhuman.inference_status -> ok
and:
openhuman.local_ai_downloads_progress -> ok
Nothing looked obviously broken.
But something important was missing.
There were 「no memory-building events」.
For example, nothing resembling:
embedded chunk
summary tree
sealed buffer
memory summarising
appeared anywhere.
This was strange.
If Summary Trees were truly being constructed, some sign of processing should exist.
Instead, there was silence.
That silence pointed toward a different hypothesis:
❝
Maybe the summarization process never actually started.
❞
Third Wrong Assumption: An Ingestion Bug
❝
「Core question:」 Did Sync succeed while chunks failed to enter memory buffers?
❞
At this stage, another theory emerged.
The logic looked like this:
Files exist
↓
Sync succeeds
↓
Chunks never enter L0 buffers
↓
Summary Tree = 0
This explanation initially seemed convincing.
After all, the symptoms aligned perfectly:
3 file(s)
but:
0 buffer(s)
From a systems perspective, it looked like an ingestion queue problem.
Maybe buffers were never flushed.
Maybe workers were stuck.
Maybe ingestion silently failed.
At this point, the investigation briefly shifted toward the possibility of an internal bug.
But eventually, that theory also collapsed.
The Real Root Cause: Summary Trees Do Not Consume Local Vault Data
❝
「Core question:」 Why do local Markdown files never enter the memory tree?
❞
The final answer turned out to be unexpectedly simple:
❝
「Summary Trees currently work only with supported external sources such as Gmail, Slack, and Notion.」
❞
This completely changed the interpretation of everything.
Even if OpenHuman showed:
3 file(s) · synced
that only meant:
❝
Files had been indexed or synchronized.
❞
It did 「not」 mean:
L0 buffer
↓
Summariser
↓
Summary Tree
would automatically happen.
In practice, the observed workflow looked more like this:
Gmail / Slack / Notion
↓
Structured events
↓
L0 Buffer
↓
Summary Tree
—not this:
Local Markdown Files
↓
Summary Tree
This explains the contradiction perfectly.
Why:
3 file(s)
and:
0 buffer(s)
can both be true simultaneously.
Because:
❝
「There are no eligible buffers to summarize.」
❞
This is not a failure.
It is product behavior.
Why the Interface Feels Misleading
❝
「Core question:」 If Vault files do not build memory, why does the UI suggest otherwise?
❞
This is arguably the most confusing part of the entire experience.
From a user perspective, the workflow feels intuitive:
Local files
↓
Sync
↓
AI understanding
↓
Memory Tree
Especially when the interface contains labels like:
-
Vault -
Sync -
Summary Tree -
Tree View -
Storage
Those labels naturally imply:
❝
“This is a local knowledge system.”
❞
But based on observed behavior, the actual product model appears closer to:
❝
「Personal digital exhaust memory」
❞
Meaning:
❝
Structured context extracted from communication systems.
❞
Not:
❝
A local RAG system for Markdown notes.
❞
This difference in expectation is exactly why troubleshooting became confusing.
The system was not broken.
The mental model was.
A Minimal Reproducible Test
❝
「Core question:」 How can you verify whether you are hitting the same limitation?
❞
Create a simple test file:
F:\12\test.md
Content:
Project: Atlas
Stack:
Rust
SQLite
No ORM
Then:
Step 1: Add Vault
Use:
F:\12
Step 2: Click Sync
If successful, the interface should show:
3 file(s)
or:
1 file(s)
This confirms:
❝
Files are being read correctly.
❞
Step 3: Build Summary Tree
If you immediately see:
Building summary trees · 0 buffer(s)
then you are likely encountering the same limitation.
At this point, the problem is probably 「not」:
-
File permissions -
File paths -
Unsupported formats -
API keys -
Embedding models
Instead:
❝
「The Vault data source is simply not eligible for Summary Tree generation.」
❞
A Reflection: Don’t Force Your Expectations onto Product Behavior
❝
「Core question:」 What is the biggest lesson from this troubleshooting experience?
❞
Looking back, one pattern became obvious.
The investigation repeatedly assumed:
❝
Something technical must be broken.
❞
So the debugging focused on:
-
File systems -
Workers -
Embeddings -
Summarizers -
Queues -
APIs
But eventually, the actual issue was simpler:
❝
The system was behaving exactly as designed.
❞
The misunderstanding came from expectation.
When a product includes concepts like:
Vault
Sync
Memory Tree
users naturally assume:
❝
“This works like Obsidian plus AI memory.”
❞
But the observed behavior suggests something different:
❝
“This works like structured memory built from communication systems.”
❞
Once that mental model changes, the entire experience suddenly becomes easier to understand.
How to Properly Test OpenHuman Memory
❝
「Core question:」 If local Vaults do not work, how should memory be tested?
❞
The simplest path is:
Connect one of the supported sources:
-
Gmail -
Slack -
Notion
Then:
1. Sync Data
Allow ingestion to finish.
2. Build Summary Tree
Click:
Build Summary Tree
3. Inspect Tree View
Expected categories may include:
People
Projects
Conversations
Tasks
Alongside:
-
Contacts -
Conversations -
Topics -
Decisions
If these nodes begin appearing:
❝
The Summary Tree is actually functioning.
❞
Practical Checklist
If You See 0 buffer(s)
Start here.
Case 1: Sync failed
If the interface still shows:
0 file(s)
Check:
-
File paths -
Permissions -
File locations
Case 2: Sync succeeded but Summary Tree is empty
If you see:
3 file(s) synced
but:
0 buffer(s)
ask this question first:
❝
“Am I only using a local Vault?”
❞
If yes:
❝
That behavior is expected.
❞
What Not to Debug First
Avoid immediately troubleshooting:
-
OpenAI keys -
Ollama -
Embedding models -
Summarizer providers
Because the root cause may not exist at the model layer at all.
One-Page Summary
| Question | Answer |
|---|---|
Is \\?\F:\12 an error? |
No. It is normal Windows path formatting |
Does 3 file(s) synced mean success? |
Yes, files were read successfully |
| Why is Summary Tree still empty? | Local Vaults do not enter Summary Trees |
| Is embedding configuration the problem? | Not the root cause |
| Is this an ingestion bug? | Ultimately, no |
| What sources work with Summary Tree? | Gmail, Slack, Notion |
| What does Vault currently do? | File sync, but not memory-tree generation |
FAQ
Why do I see 3 file(s) but still get 0 buffer(s)?
Because synchronization and memory summarization are separate processes.
Local Vault files sync successfully but do not automatically enter Summary Trees.
Is 0 buffer(s) an error?
No.
It simply means:
❝
There are no eligible buffers to summarize.
❞
Does \\?\F:\12 mean my path is broken?
No.
That is standard Windows internal path formatting.
Do I need to configure embeddings?
For this specific issue:
❝
Probably not.
❞
The limitation appears at the data-source layer.
Can local Markdown files become memory?
Based on observed behavior:
❝
Not through Summary Trees.
❞
At least not in the tested workflow.
How do I confirm memory is actually working?
Connect:
-
Gmail -
Slack -
Notion
Then sync and rebuild Summary Trees.
Why is this issue confusing?
Because the interface strongly suggests:
Vault
↓
AI Memory
But the actual behavior is different.
What is the biggest takeaway?
One sentence:
❝
「Understand the product boundary before debugging the technology.」
❞
