Context
This is about a local Cognee memory-provider integration used with Hermes on macOS. The Cognee plugin itself is not currently tracked in upstream NousResearch/hermes-agent, but the behavior gap is specific to the Hermes memory-provider contract / runtime environment and needs a canonical issue reference for the local patch.
Problems
1) Lance-backed recall fails under the default macOS soft maxfiles limit
In a live Hermes gateway process, cognee_recall failed with:
LanceError(IO): Too many open files (os error 24)
Observed runtime state:
- process soft maxfiles limit:
256
- live gateway process already had ~
219 FDs open before recall
- Cognee/Lance needed more headroom during recall
For this integration, a local fix raises RLIMIT_NOFILE to 4096 at provider initialization / recall-sensitive paths. A fresh process verified the helper raises 256 -> 4096 successfully when the hard limit allows it.
2) Built-in Hermes memory writes were not mirrored into Cognee
Hermes MemoryProvider exposes on_memory_write(action, target, content) specifically for mirroring built-in memory writes, but the local Cognee provider only handled:
prefetch()/queue_prefetch()
sync_turn()
on_session_end()
Result: memory / user writes made through Hermes did not land in Cognee's durable graph lane.
A local fix adds on_memory_write() support for add / replace and mirrors those writes into Cognee's permanent remember path.
Why this matters
Without these two behaviors:
- live Cognee recall in gateway sessions can fail under normal macOS limits
- Hermes built-in durable memories and Cognee drift apart semantically
Local fix shape
- best-effort
RLIMIT_NOFILE raise in the provider before Lance/Kuzu-heavy operations
on_memory_write() implementation that mirrors add / replace writes into Cognee permanent memory
- regression tests for both behaviors
Requested outcome
Even if Cognee is not merged upstream today, keep this issue as the canonical reference for the integration gap so the behavior is not lost:
- provider integrations backed by Lance/Kuzu need a maxfiles strategy on macOS
- memory providers intended for durable parity should implement
on_memory_write()
Context
This is about a local Cognee memory-provider integration used with Hermes on macOS. The Cognee plugin itself is not currently tracked in upstream
NousResearch/hermes-agent, but the behavior gap is specific to the Hermes memory-provider contract / runtime environment and needs a canonical issue reference for the local patch.Problems
1) Lance-backed recall fails under the default macOS soft maxfiles limit
In a live Hermes gateway process,
cognee_recallfailed with:Observed runtime state:
256219FDs open before recallFor this integration, a local fix raises
RLIMIT_NOFILEto4096at provider initialization / recall-sensitive paths. A fresh process verified the helper raises256 -> 4096successfully when the hard limit allows it.2) Built-in Hermes memory writes were not mirrored into Cognee
Hermes
MemoryProviderexposeson_memory_write(action, target, content)specifically for mirroring built-in memory writes, but the local Cognee provider only handled:prefetch()/queue_prefetch()sync_turn()on_session_end()Result:
memory/userwrites made through Hermes did not land in Cognee's durable graph lane.A local fix adds
on_memory_write()support foradd/replaceand mirrors those writes into Cognee's permanent remember path.Why this matters
Without these two behaviors:
Local fix shape
RLIMIT_NOFILEraise in the provider before Lance/Kuzu-heavy operationson_memory_write()implementation that mirrorsadd/replacewrites into Cognee permanent memoryRequested outcome
Even if Cognee is not merged upstream today, keep this issue as the canonical reference for the integration gap so the behavior is not lost:
on_memory_write()