Env Probe

Somebody on Discord asks what GPU you run, or a node you installed compiles a CUDA extension and fails in a way that only makes sense if you know your compute capability. You can't get to a terminal because your ComfyUI lives on a cloud box (RunComfy, say), or you just don't feel like spelunking through pip show torch. That's exactly the gap Env Probe fills: one node, no inputs, press queue, get a full readout of the runtime your ComfyUI is actually sitting on.

It's the diagnostics half of a Human3R port - the author ships it so you can figure out a wheel-versus-compile strategy without terminal access. But you don't need to care about Human3R at all. It's a tiny, dependency-free environment probe that happens to be useful every time a "why won't this run on my machine" argument breaks out.

What it actually reports

Run it and you get a text block with three sections:

• Python and platform - sys.version and platform.platform(). Instantly tells you if you're on Windows/Linux and which Python the embedded runtime is using.
• The torch block - torch.__version__, torch.version.cuda (the CUDA version torch was built against, not your driver), the cuDNN version, whether CUDA is available, your device count, and each GPU's name plus compute capability like sm_89. That last one is the gold: sm_89 tells you which prebuilt wheels a given extension supports before you try to compile and watch it die.
• A dependency import check - it tries to import numpy, smplx, roma, trimesh, gsplat, einops, cv2 and reports OK + version or MISSING. These are the Human3R-relevant packages, so on a fresh box you'll see a wall of MISSING. That's not a bug - that's the report doing its job, telling you what a workflow's prerequisites will drag in before you install them.

Everything's wrapped in try/except, so the node never crashes your graph. No CUDA, no torch, weird cuDNN build - it reports it and moves on.

How it works

Under the hood it's a classic OUTPUT_NODE with an empty required dict: no inputs at all, so it executes standalone on an empty graph. It builds the report, prints it to the server console, and returns it as a single STRING output named report and pushes the text to its own UI panel. Three surfaces, one report.

One detail worth knowing: the node's IS_CHANGED always returns NaN, which tells ComfyUI to never treat it as cached. It re-runs every single time you queue, so you're never staring at a stale report from three updates ago. When you're diagnosing, that's exactly what you want.

Installing it

The README is one line long on dependencies: none, and nothing to compile. Install it however you install custom nodes:

cd ComfyUI/custom_nodes
git clone https://github.com/SchwenderOne/ComfyUI-EnvProbe

Then restart ComfyUI (or hit refresh in Manager). On RunComfy, the README suggests ComfyUI Manager → Install via Git URL, or drag-dropping the folder into custom_nodes via the web file browser. Either way: restart, then right-click → Add Node → search Env Probe (it lives under utils/debug).

Using it and troubleshooting

Add the node to an empty graph and press Queue Prompt. Read the report off the node's own panel or the server log. If you want a copy to paste into a GitHub issue or a support thread, wire the report output into any Show Text / Preview Text node - it's a plain string, so it flows anywhere text flows. There's even an API-format workflow (workflow_envprobe_api.json) in the repo for headless comfy run --workflow use.

Things people trip on, grounded in how it's built:

• The wall of MISSING is the point. It's a probe, not an installer. It tells you what's absent so you know what a Human3R-style workflow needs before you commit to the install.
• Don't expect it to fix anything. This is read-only diagnostics. It tells you why a compile might fail (wrong compute capability, torch built against an older CUDA) - the fix is on you.
• No GPU, no problem. On a CPU-only box it just prints torch.cuda.is_available = False and skips the device lines instead of erroring.

It's a humble tool - one output, zero inputs, zero dependencies - but it's the first thing I reach for when someone says "it works on my machine." Now you can find out whose machine is the problem.