Documentation Index
Fetch the complete documentation index at: https://supermemory.ai/docs/llms.txt
Use this file to discover all available pages before exploring further.
supermemory-bash is the SMFS idea wrapped as a single agent tool: run_bash(command). The “filesystem” is your Supermemory container. Runs anywhere Python runs. AWS Lambda, Modal, Fly Machines, Cloud Run, your laptop. No mount, no FUSE, no local disk.
Reach for the Bash Tool when your agent runs somewhere it can’t mount a real filesystem.
Install
Quickstart
create_bash returns a CreateBashResult with:
bash: aShellinstance with.exec(cmd)tool_description: a pre-written tool description ready to hand to the modelconfigure_memory_paths(paths): scope which paths get extracted into Supermemoryrefresh(): re-prime the path index after external writes
Use it as a model tool
Anthropic SDK
Passtool_description straight into Claude’s tool definition and run a normal agent loop. Each tool_use block calls bash.exec and the result goes back as a tool_result.
OpenAI SDK
Same idea with OpenAI’s function-calling format. Define a singlebash function, dispatch each tool_calls entry to bash.exec, and feed the output back as a tool message.
Claude Agent SDK
The Claude Agent SDK ships with built-inBash, Read, and Write tools. If your agent runs somewhere SMFS can be mounted (a long-lived process on macOS or Linux), point those built-ins at an SMFS mount and you don’t need supermemory-bash at all — the agent just sees your container as a directory.
See Mount SMFS for setup, or the provider guides for sandbox-specific instructions.
Memory
The Bash Tool inherits SMFS memory semantics. By default, files nameduser.md or memory.md are extracted as memories. Configure additional memory paths after construction:
/ matches recursively. No slash matches an exact file. Pass [] to disable memory generation.
The container also exposes a virtual profile.md at the root: a live digest of everything in the container. Read it once at the start of a session to give the model context without walking every file.
Commands the agent can run
The Python tool exposes the same command surface as the TypeScript version: standard Unix builtins (pwd, cd, ls, cat, stat, mkdir, rm, mv, cp, echo), search and text utilities (grep, find, head, tail, wc, sort, sed, awk), plus the custom sgrep <query> [path] for semantic search across the container. Pipes, redirects, conditionals, loops, and file tests all work.
See the TypeScript Bash Tool reference for the full list.
Configuration
| Option | Default | Purpose |
|---|---|---|
api_key | required | Supermemory API key |
container_tag | required | Container to expose as the filesystem |
base_url | None | Override the API endpoint |
eager_load | True | Warm the path index when the instance starts |
eager_content | True | Also warm the content cache during eager load |
cwd | "/home/user" | Initial working directory |
env | None | Extra environment variables |
cache_ttl_ms | 150_000 | Content cache TTL in ms. None = never expires (single-writer). 0 = no cache. |
cwd or extra env from the host doesn’t change the files the agent sees.
Limitations
chmod,utimes, and symlinks (ln -s,readlink) raiseENOSYS./dev/nullas a redirect target isn’t supported. Write to/tmp/discard.loginstead.- Binary uploads aren’t supported. Text is extracted server-side.