Drop host-filesystem nodes from the production node surface

[georgi]

Problem

In production we don't want file-access nodes like the document file input.

The cloud profile (NODETOOL_ENV=production → cloud, unless NODETOOL_NODE_PROFILE=full) already curates the catalog down to the creative node set, but it whole-lists nodetool.input, nodetool.image, nodetool.audio, nodetool.video, and nodetool.model3d. The nodes inside those namespaces that read and write paths on the server's own disk therefore survived.

nodetool.input.DocumentFileInput is the one users hit first: a native file picker rendered in a browser tab that can only ever point at the container's filesystem, not the user's machine.

The matching HTTP surfaces are already refused in production — /api/files/local (file-api.ts:163), the workspace routes (workspace-api.ts:76), tRPC files.list (trpc/routers/files.ts:46). So these nodes were offering a picker that cannot pick and a run that cannot resolve.

Change

Collect the offenders in a new CLOUD_HOST_FILE_NODES and embed it in the existing CLOUD_NODE_DENYLIST (packages/protocol/src/cloud-profile.ts). applyCloudNodePolicy already unregisters denied types at bootstrap, so the palette, /api/nodes/metadata, and the runner all agree with no new mechanism.

Thirteen node types, all verified to exist in the registry (a typo here would be a silent no-op):

Path pickers	nodetool.input.DocumentFileInput, FilePathInput, FolderPathInput
Audio	LoadAudioFile, LoadAudioFolder, SaveAudioFile
Image	LoadImageFile, LoadImageFolder, SaveImageFile
Video	LoadVideoFile, SaveVideoFile
3D	LoadModel3DFile, SaveModel3DFile

Assets stay. They're how the cloud moves files: the *Assets loaders, AssetFolderInput, DocumentInput, and the plain SaveImage/SaveAudio/SaveVideo/SaveModel3D savers are untouched, and a test pins that.

Why the list is written out rather than derived

Two shapes needed naming, and only one is visible in metadata:

• Most declare a picker property (json_schema_extra: { type: "file_path" }) — detectable.
• The rest (LoadAudioFile and friends) take a plain str prop and call fs in process(). Nothing in their metadata distinguishes them from any other string node.

So the list is explicit, and a registry-level drift guard covers the detectable half: a test asserts no node with a file/folder picker property survives the policy, so one added later inside an allowed namespace fails CI instead of shipping. I verified the guard actually fails by temporarily removing DocumentFileInput from the list — it caught it — then restored.

Nodes that use scratch files under os.tmpdir() (ffmpeg work in nodetool.video.* and nodetool.timeline.*) are not host file access and correctly stay; I checked each against its source rather than trusting an fs grep.

Scope

Self-hosted deployments running NODETOOL_NODE_PROFILE=full are unaffected, consistent with the rest of the cloud curation. I deliberately did not gate on bare NODETOOL_ENV=production, which would override that documented opt-out — say the word if you'd rather these nodes be gone on every production server regardless of profile.

No shipped example workflow references any of the removed nodes (checked). Existing user workflows in the cloud that contain one will now fail validation up front rather than at the node — those runs could not have resolved a host path anyway.

Testing

• packages/protocol: 794 tests pass; added coverage that the host-file nodes are denied and their asset counterparts are kept.
• packages/websocket node-registry-setup: 19 pass, including the new drift guard.
• npm run lint passes; root npm run typecheck passes.

Two pre-existing environment failures, confirmed identical on a clean tree via git stash: electron's typecheck and 26 websocket test files fail to import because packages/websocket/dist and @nodetool-ai/dsl aren't built in this sandbox. All 1918 collected websocket tests pass.

---

Generated by Claude Code