[MichielMAnalytics]

I work on boxd. This adds an SMFS provider guide for boxd machines, next to the Daytona and E2B guides. A boxd machine is a full Ubuntu VM with FUSE, Python, uv and systemd, so SMFS mounts there without a custom image.

Summary

• New page apps/docs/smfs/providers/boxd.mdx. It mirrors e2b.mdx and daytona.mdx: how it works, prerequisites, a shared install and mount snippet, Pattern A (agent inside the machine) and Pattern B (agent outside), each in Python and TypeScript, and tips.
• apps/docs/docs.json: appended smfs/providers/boxd to the SMFS Providers group.
• apps/docs/smfs/overview.mdx: appended a boxd card to "Use SMFS with your sandbox provider".
• Docs only. No code, packages or workflows change.

How the page wires SMFS into a machine

Step	boxd
Create	machines.create(isolated=True, delete_after=1800) + wait_until_ready
Install	curl -fsSL https://smfs.ai/install | bash -s -- 0.0.5, plus user_allow_other in /etc/fuse.conf if it isn't there yet
Mount	smfs login, then smfs mount started with systemd-run -p Type=forking, so it keeps running after the command returns, and systemd-run returns once SMFS reports the mount is ready. The examples raise if this step exits non-zero
Write access	sudo chown boxd:boxd /home/boxd/memory, so the agent can write without sudo (the E2B page wraps writes in sudo instead)
Run the agent	files.upload + exec(["uv", "run", "--with", "claude-agent-sdk", "python3", "/home/boxd/agent.py"])
Keys	passed per command with env, not at create time
Teardown	smfs sync my_agent to push pending writes, then machines.delete in a finally block, with the delete-after timer as a backstop if the script dies. Or machines.hibernate / machines.wake to keep the machine and its mount

How I tested it

I ran every code block on the page against real boxd machines (Python SDK boxd 0.3.1, TypeScript @boxd-sh/sdk 0.3.1). A script pulled the snippets out of the MDX, so the tests ran the page as written. The test copies changed only the machine name and added checks.

The last run used the hosted API (api.supermemory.ai) with the page exactly as written. After each script deleted its machine, I listed the documents for the my_agent container tag in the hosted account. That run found one gap: the examples deleted the machine before SMFS had pushed the last write, so session_notes.md never reached the account. The page now runs smfs sync my_agent before the delete, and the hosted rows below are from the page with that step.

The earlier runs were before I had a hosted key. Each test machine ran supermemory-server 0.0.9 (npx supermemory local), and the test copies added --api-url http://localhost:6767 to smfs login and smfs mount.

Check	Result
Hosted API, Pattern B, Python	pass: every command exit 0, smfs login validates the key, ls shows profile.md and session_notes.md, and after the machine is deleted the account lists /session_notes.md as done with the line the script wrote, 14 s end to end
Hosted API, Pattern B, TypeScript	pass: same results, 15 s
Hosted API, Pattern A, Python	pass, with a real Anthropic key: the agent runs 4 turns with cwd=/home/boxd/memory, reads profile.md and writes session_notes.md, and after the machine is deleted the account lists /session_notes.md as done with the agent's text, 23 s end to end
Hosted API, Pattern A, TypeScript	pass: same results, 26 s
Hosted API, smfs sync	a write shows up in the account as queued about 2 s after it lands on the mount; smfs sync my_agent returns after the push, and the document is done right after it returns (3 of 3)
Self-hosted server, Pattern B, Python	pass: every command exit 0, ls shows profile.md and session_notes.md, server lists /session_notes.md as done, 33 s end to end
Self-hosted server, Pattern B, TypeScript	pass: same results, 30 s
Self-hosted server, Pattern A, Python	pass, with a real Anthropic key: install, mount and upload exit 0, the agent runs 4 turns with cwd=/home/boxd/memory, reads profile.md and writes session_notes.md, and the server lists /session_notes.md as done, 43 s end to end
Self-hosted server, Pattern A, TypeScript	pass: same results, 42 s
Failure paths, Pattern B, Python and TypeScript	with an invalid Supermemory key the mount step exits 1 and the script raises SMFS mount failed with the stderr; with an error thrown at a later step the script fails too. In both cases the finally block deleted the machine, and a lookup by id returned not found. The delete-after timer was set on every machine; I didn't wait 30 minutes to watch one fire
Tips	systemctl status smfs-my_agent active; smfs grep 'what language does the user like' returned the matching note; after hibernate and wake the unit was still active and the files were readable; systemctl stop unmounts; after a remount, both files came back from the server
bun install --frozen-lockfile (bun 1.3.6)	clean
bunx biome ci --changed --since=origin/main --no-errors-on-unmatched	clean
mintlify broken-links (mintlify 4.3.10)	no broken links found
mintlify dev	/smfs/providers/boxd renders, and the overview links to it

Links

• boxd docs: https://docs.boxd.sh?ref=supermemory
• Python SDK: https://pypi.org/project/boxd/
• TypeScript SDK: https://www.npmjs.com/package/@boxd-sh/sdk

[mintlify]

Preview approval required

This pull request comes from a fork, so Mintlify won't build a preview until someone with write access approves commit daadcdb.

Approve preview