funes turns agent transcripts into shared memory. Treat the dataset as sensitive
Coding agents forget for a mundane reason: the useful investigation often ends up trapped in a transcript on one machine. Switch laptops or agents and the code remains, but the reasoning that produced it does not.
The new open-source tool funes indexes session traces from Claude Code, Codex, pi, and Hermes, then exposes recall and get tools. A local memory can also be published as a Hugging Face dataset for another machine or teammate to search.
That convenience comes with a different security boundary. Transcripts may contain commands, paths, abandoned ideas, business context, credentials, and material copied from untrusted sources. Once they become a searchable shared dataset, they need the controls used for production data, not merely a better system prompt.
It keeps the evidence, not just a summary
funes is a single Rust binary. Its repository documentation says it converts supported agents' traces into a common turn-and-block format. It chunks and embeds the text with a pinned local model, stores it in a Lance dataset, combines vector and BM25 retrieval, reranks candidates, applies a recency weight, and includes neighboring chunks.
recall returns original passages together with the agent, timestamp, session, and turn. get opens the surrounding context. The trace is not promoted into a permanent fact simply because it entered the index.
That provenance is the design's best feature. A later agent can read the passage behind “we rejected the streaming parser” instead of trusting a compressed handoff. The memory is not tied to the model that created it either. Embedding and reranking models are local and pinned. The reasoning agent can change from one session to the next.
Local use stays local. Parsing, chunking, embedding, and reranking run on the user's machine. For remote recall, dataset files are downloaded to a local cache and queried there. According to the project's security policy, the Hub stores a published dataset but does not process the query.
Publishing changes the risk
Local indexing and remote publishing should be treated as separate risk classes. When a memory is bound during funes add, hooks can push it at session boundaries. Repositories created by funes are private by default, but an existing repository keeps its current visibility. The documentation tells users to check that visibility before uploading history they do not want exposed.
There are several credential defenses. funes redacts credentials while indexing. Before upload, an always-on TruffleHog gate scans every outgoing chunk and withholds rows containing detected secrets. If the scanner is missing or crashes, the push fails closed. funes scrub removes secrets from an existing local memory.
The recovery procedure shows why prevention still matters. If a secret reaches a remote memory, blocking later rows does not repair the leak. The policy instructs the user to rotate the credential, delete the dataset repository, recreate it, and push a scrubbed memory. Removing the secret in a later commit does not remove it from repository history.
Access tokens should follow the same split. funes recommends fine-grained Hugging Face tokens: write access on machines that publish, and read-only access for machines or teammates that only recall. Sharing one personal token would collapse that boundary.
The installer has a narrower supply-chain limitation. It checks the downloaded binary against the release checksum and version. The README notes that the binary and SHA256SUMS are served from the same bucket, so the checksum can detect corruption or mismatch but cannot independently authenticate that bucket. Teams with stronger requirements can inspect the Apache-2.0 source and build the binary themselves.
Remembered text can carry instructions
A shared memory is also a route into the agent's context. The security policy warns that third-party memories may contain prompt injection. A retrieved passage can try to redirect the agent once it is placed beside the user's request.
The project advises users to bind only memories they trust. For a one-off search of a third-party dataset, it recommends a per-call memory rather than a permanent default:
funes recall "why is funes append-only" --memory huggingface/funes-memory
The same rule belongs inside organizations. “Internal” describes access; it does not make every passage trustworthy. A session trace can include issue text, web pages, logs, generated code, and terminal output. Any of those sources can carry hostile instructions without a teammate intentionally planting them.
Run recalled passages under the same least-privilege tool policy used for fresh external content. Provenance helps an investigator locate the source, but it does not make the instruction safe. Our earlier article on memory authority drew this line for preferences and factual claims. funes adds another case. Remembered text may be useful and properly attributed while remaining unsafe to follow.
The benchmark is useful and deliberately small
The launch article says recall was eight times cheaper than a written handoff on one task and four times cheaper on another. The accompanying handoff-versus-recall dataset publishes traces, hidden-grader results, token receipts, its weighting rule, and isolation requirements.
The experiment covers two recommendation tasks and three repetitions per arm. One task examined reranking performance on Apple silicon; the other evaluated candidate recall features. The result shows that retrieval can beat carrying or summarizing a long investigation in those cases. It is not a general benchmark of memory quality, latency, or team productivity.
Compaction succeeded on one task and failed on the other after its summary omitted findings required by the grader. That is a concrete reason to preserve source passages, but it does not prove that compaction usually fails. The benchmark authors explicitly avoid that broader claim.
This complements BLOGish's earlier look at recoverable context compaction. Summaries become safer when omitted material remains traceable. funes starts from the other end by retrieving the original material when it is needed.
Roll out one bounded memory first
Start with a limited set of sessions on one machine. Inspect what appears in recall, including thinking blocks, tool output, and paths. Use --no-thinking when reasoning traces should stay out of the dataset. Put a session limit on the first index as well.
Test the publishing failure path with synthetic credentials next. Confirm that the outgoing scan blocks the push and that scrub removes the row locally. Make sure an alert reaches the person responsible for the dataset. Create separate read and write tokens, then check repository visibility from an account without privileged access.
Add one controlled prompt injection to a test trace. Verify that the agent handles the recalled passage as evidence rather than authority, and restrict its tools during the exercise. Retrieval logs should identify the source session and turn so an incident can be reconstructed.
For teams switching models through a shared layer such as api.ish.chat, portable memory can separate historical context from the provider in use. The security design should keep those components separate too. The model endpoint, memory dataset, and tools each need distinct credentials and audit trails.
funes makes an agent's past reusable by preserving source material instead of flattening it into a summary. It also preserves the untidy contents of a real working session. Once that memory is shared, operate it as production data. A later cleanup commit will not rescue a secret already written into remote repository history.



