Practical overview
When it fits
Use smfs when an agent or local workflow needs file-based access to a Supermemory container, especially when semantic search or synchronization across environments is part of the workflow.
Who it is for
- Agent developers who want file-based access to persistent Supermemory containers.
- People using editors, scripts or other local tools to work with a shared agent memory directory.
- Developers building agents in serverless, edge or browser-based runtimes without a local filesystem.
Documented uses
- Read and edit memory files through familiar filesystem operations.
- Keep local file changes synchronized with a Supermemory container.
- Search container content semantically through `grep` in a mount or `sgrep` in the virtual bash tool.
- Choose which paths feed Supermemory’s memory-processing pipeline.
Requirements & limits
The README requires a Supermemory API key. The repository lists an MIT license.
- Choose a directory mount when the runtime has a kernel and filesystem; choose the virtual bash tool for runtimes without one.
- Only configured memory paths are processed into structured, semantically searchable memories; other files remain durable storage.
- Mounted writes upload in the background, and remote changes are pulled every 30 seconds by default.
- Docker use requires FUSE access to
/dev/fuseand theSYS_ADMINcapability.
Check current requirements in the official documentation. Source-based guidance does not mean OpenViST has run or independently tested this project.
Mount a Supermemory container as a directory
Authenticate smfs and access a named container through a local folder.
Before you start
- macOS or Linux on arm64 or x64
- A Supermemory API key
- A Supermemory container tag
Steps
Install smfs using the documented install script.
Run
smfs loginto store the API key locally.Run
smfs mountto mount the container in the current directory.Use ordinary file tools to inspect or edit files, then run
smfs unmountwhen finished.
Expected outcome
The named container is available as a local directory; writes upload in the background and remote changes are pulled every 30 seconds by default.
Guide limitations
- Only files under the container’s memory paths enter the memory-processing pipeline; other files are durable storage only.
- The documented macOS and Linux installation supports arm64 and x64.
Connect an agent with the virtual bash tool
Give an agent in a runtime without a local filesystem access to a Supermemory container.
Before you start
- A TypeScript runtime
- A Supermemory API key
- A container tag
Steps
Import
createBashfrom@supermemory/bash.Create the bash tool with the API key and container tag.
Expose the returned bash tool to the agent and use it for file operations or
sgrepsemantic search.
Expected outcome
The agent can use the virtual filesystem interface and search the container semantically with `sgrep`.
Guide limitations
- The README describes this route for runtimes without a local filesystem, including serverless, edge and browser-based agents.
- The package quickstart and full options are in the repository’s bash README.
Sources & review
Source record details
- Source availability
- Active
- Sources checked
- 9 October 2026
- Original website title
- supermemoryai/smfs · Official homepage title · retained in its source language

