Skip to main content
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

Or with uv:

Quickstart

create_bash returns a CreateBashResult with:
  • bash: a Shell instance with .exec(cmd)
  • tool_description: a pre-written tool description ready to hand to the model
  • configure_memory_paths(paths): scope which paths get extracted into Supermemory
  • refresh(): re-prime the path index after external writes

Use it as a model tool

Anthropic SDK

Pass tool_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 single bash 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-in Bash, 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 named user.md or memory.md are extracted as memories. Configure additional memory paths after construction:
Trailing / 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

OptionDefaultPurpose
api_keyrequiredSupermemory API key
container_tagrequiredContainer to expose as the filesystem
base_urlNoneOverride the API endpoint
eager_loadTrueWarm the path index when the instance starts
eager_contentTrueAlso warm the content cache during eager load
cwd"/home/user"Initial working directory
envNoneExtra environment variables
cache_ttl_ms150_000Content cache TTL in ms. None = never expires (single-writer). 0 = no cache.
The container is what defines the filesystem; setting cwd or extra env from the host doesn’t change the files the agent sees.

Limitations

  • chmod, utimes, and symlinks (ln -s, readlink) raise ENOSYS.
  • /dev/null as a redirect target isn’t supported. Write to /tmp/discard.log instead.
  • Binary uploads aren’t supported. Text is extracted server-side.