Share code between code nodes

A code node’s project files belong to that one node. When two nodes need the same classifier, parser, or formatting rule, copying it into both is the obvious move — and the wrong one: the copies drift, and nothing tells you when.

The shared library is where that logic belongs. It is one lib/ tree per workspace. Every code node sees it at /sc/lib/ when it runs, and repo-sync keeps the lib/ folder of your workspace repo as its single source of truth.

Add a shared module

1. Open Settings → Data & sync → Shared library.

2. Use New file in the editor’s file tree and give it a path relative to the library root — mail_triage.ts, or pdf/stage0.py for a subfolder. Do not prefix it with lib/; that prefix is added for you.

3. Write the module and press Save.

The header shows the Import as line for the selected file. That is the exact specifier a code node needs — copy it rather than typing one from memory, because the two runtimes disagree about what a valid one looks like.

Import it from a code node

The library lands at /sc/lib/, next to the node’s entry file at /sc/main.ts (or /sc/main.py). This works in every code-node mode — inline, script, and project — so a node whose source lives in your workflow YAML can import a shared module without changing anything else.

TypeScript (Deno)

import { classify } from "./lib/mail_triage.ts";

const bucket = classify(subject);

The leading ./ and the .ts extension are both required. Deno does not infer extensions and does not resolve bare specifiers to local files, so import { classify } from "mail_triage" fails — this is the single most common mistake when porting code from Node.

Python

import lib.pdf_stage0
from lib.pdf_stage0 import classify

kind = classify(raw_bytes)

The extension is dropped and folders become dots: pdf/stage0.py is lib.pdf.stage0. This works because Python puts the entry script’s directory (/sc) at the front of the import path — you need no sys.path line and no __init__.py file.

A node's own file wins

If a code node’s own project files already contain lib/util.ts, that file is used and the shared util.ts is not placed over it. Adding something to the shared library can never silently replace a file a node already had.

Keep the repo as the source

With repo-sync configured, the shared library round-trips through the lib/ folder of your workspace repo — with no wrapper file and no metadata header, so the file you review in a diff is exactly the file that runs.

• Push writes every shared file to lib/<path>.
• Pull brings changes back and removes files you deleted in the repo. This is the one place a pull deletes: a shared library whose deletions do not propagate stops being a single source and becomes a cache that only grows.

A file you edited in the UI more recently than the incoming commit is kept, not overwritten and not pruned — the same last-write-wins rule the rest of repo-sync uses.

Limits

Files per workspace	64
Size per file	256 KiB
Content	Text only

Text-only is deliberate: the repo’s lib/ folder is this library’s single source, and a push writes text files. A binary file could not travel that path — it would live in the database, never show up in a diff, and quietly break the guarantee the library exists for. Put binary assets in the code node’s own project files instead.

Shared files are not templated

${{ steps.… }} and ${{ trigger.… }} placeholders are substituted in a code node’s own source, but not in a shared file — it reaches the container exactly as it is in the repo. A library is written once and imported by many nodes, so a per-run substitution there would make the same file behave differently in each one. Pass per-run values into your shared functions as arguments.

See also

• Manage memories — the other workspace surface that round-trips through the synced repository.
• Runs and tasks