Files and repositories

The built-in LLM agent runs with an ephemeral disk: anything written during a run is wiped when the run ends. The five CLI harnesses keep a per-conversation /workspace folder that survives across runs on its own, so an agent’s saved notes and files are still there when it wakes up again. The Filesystem node adds a named persistent volume to any agent, and a GitHub tool provider can clone repositories into the sandbox with authenticated git.

​

The filesystem node

Wire a Filesystem node from its top handle into the agent’s bottom handle, or add it from the agent’s Add tool palette. 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.

​

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.
• The five CLI harnesses keep their /workspace folder across runs even without a filesystem node, so an agent’s saved notes and files survive a restart. Wiring a filesystem node makes that storage explicit and lets you choose its volume mode and browse its files.
• For the built-in LLM agent, the whole sandbox disk is ephemeral without a filesystem node.

​

Publish a file to a URL

Whenever an agent runs in a sandbox, it has an upload_file tool. Give it the path to any file the sandbox can read and it uploads the file to the workflow’s resource storage and returns a public URL, so the agent can share a generated image, attach a report to an email, or pass the file to a downstream node. You do not need a filesystem node for this: the five CLI harnesses always run in a sandbox, and the built-in LLM agent runs in one whenever a filesystem node or a repository mount is wired.

​

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. At the start of every run, each repo is cloned into the agent’s sandbox with push access. Inside the sandbox, both git and the gh CLI are authenticated with the node’s credential, so the agent can commit, push, and open pull requests. Prefer the GitHub node’s allowlisted API tools for issue and PR operations; they are audited per call. The authenticated 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