The filesystem node
Wire a Filesystem node from its top handle into the agent’s bottom handle. The agent gets a bash tool and a mounted volume whose contents persist across runs. For the built-in LLM agent, wiring a filesystem node is also what enables bash in the first place; the CLI harnesses always have a sandbox shell.| Setting | What it does |
|---|---|
| Volume Mode | Shared (all executions): one volume for every run. Per Conversation Key (isolated per user): a separate volume per conversation key |
| Mount Path | Where the volume appears inside the sandbox (default /workspace) |
| Files | A browser in the node’s config panel for inspecting what the agent has stored |
What persists, what doesn’t
- Files under the Mount Path persist across runs (and across harnesses, since the volume is keyed to the workflow and node).
- Everything outside the mount path is ephemeral and wiped after each run.
- Without a filesystem node, the whole sandbox disk is ephemeral.
GitHub repository mounts
A GitHub node wired as a tool provider has a Mount repositories section in its panel. Click + Add repository, pick a repo from the dropdown (it lists what the connected credential can access), and optionally a branch.
git and the gh CLI are authenticated with the node’s credential, so the agent can commit, push, and open pull requests.
Repo working trees are wiped after the run unless a filesystem node is attached. Have the agent commit and push its work rather than leaving changes on disk.
gh CLI is the fallback for anything the tools don’t cover. Use fine-grained personal access tokens to limit what a mounted credential can reach.
Next steps
Conversations
Pair per-conversation volumes with conversation keys.
Models and harnesses
See which harnesses run in a sandbox.