Skip to main content
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.
Filesystem node configuration panel

Filesystem node config with volume mode, mount path, and the file browser

​
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.

​
Browse saved files from chat

Every agent chat has a Files menu that lists what the agent saved in the current conversation’s workspace. Open a file to preview it in place (text, markdown, code, or an image) or download it with one click. Files the agent just wrote can take a few seconds to show up, and a refresh button reloads the list.
Files menu open on an agent chat with a folder tree of saved files

The Files menu on an agent chat, listing the conversation's saved files

​
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.
Repository mount rows with repo and branch pickers

The Mount repositories section on a GitHub tool provider

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.
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.
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.

​
Environment variables

You can give an agent its own environment variables so it can call APIs that NoClick has no node for. Open the agent’s Credentials panel, expand Advanced, and under Environment variables create a set: name the set, then add each variable as a name and value (for example STRIPE_KEY). The set is saved as a reusable credential, so you can link the same one to more than one agent. Each variable is available in the agent’s sandbox shell, so the agent can reference it directly:
When you edit a set, the variable names are prefilled but the values are not. Saved values are never shown again, so re-enter a value to keep it and leave it blank only when you mean to remove that variable. The AI builder can also request these for you. When it decides an agent needs a variable that is not set yet, it asks for it in the builder chat with the names it needs prefilled, and you enter the values there. It only asks when no node exists for the API the agent has to call.
Variable names are not written into the agent’s prompt, but the agent can print a value by running a command in its sandbox. Scope each key to only what the agent needs, the same way you would a mounted repository token. For a secret the agent must never see, wire an HTTP Request node as a tool provider instead.

​
Next steps

Conversations

Pair per-conversation volumes with conversation keys.

Models and harnesses

See which harnesses run in a sandbox.