Client Proxy Node

Most ComfyUI nodes get their values from widgets or wires that live on the server. Client Proxy is the opposite shape: it takes an integer in, then stops and waits for the browser tab to hand it the answer. That's the whole job, and it's where the name comes from - it's the backend half of a "client proxy" pattern for getting a value that only exists in the frontend into the middle of a running graph.

Here's the mechanism, straight from the source. When the node executes, it does two things. First it fires a "proxy" message to the frontend over ComfyUI's own messaging (PromptServer.instance.send_sync), carrying its instance's node id along with the current input value. Then it blocks, polling every 0.1 seconds, until something posts a reply to the /proxy_reply HTTP route the pack registers. The reply is matched back to the node by id, and the node returns it as its output. Full round trip: backend asks, browser answers, graph continues. The node's IS_CHANGED returns NaN - the classic always-rerun trick - so it asks fresh on every queue pass, which is exactly what you want when the value is supposed to come from the browser each time.

What it takes in and hands out

• input (optional, INT) - the value shipped to the browser as context. It's optional, so you can leave it unconnected; the node works fine as a pure "wait for the browser" pass-through.
• out (INT) - the browser's answer, passed downstream. That's the only output.

Every instance is also tracked by its internal ComfyUI node id, which is how the reply gets routed to the right node when you have several in a graph.

The honest gotcha: the browser half isn't in this pack

This is where it gets you. The shipped JavaScript (web/js/example.js) only wires up the pack's other node - nothing listens for the "proxy" event, and nothing ever POSTs to /proxy_reply. So exactly as it ships, if this node actually executes in your graph it will wait forever. The wait loop has no timeout; your only exits are bypassing the node or restarting ComfyUI. It's a scaffold demonstrating the pattern, not a finished passthrough, and it sits under "proxies" in the node menu more out of aspiration than use.

When you'd actually reach for it

Almost never as-is. If you're writing a custom node that needs a browser-computed value mid-run - a canvas click, a custom widget, a fetch against some external API from the frontend - this is a working reference for the pattern: copy MessageHolder and the /proxy_reply route, then register your own frontend listener and have it post the reply. That's a legitimately useful thing to copy. If you just need to pass an integer around a workflow, use a core PrimitiveInt instead; it won't hang on you and it's maintained.

Installing it

Same as the rest of the pack: ComfyUI Manager → search "displayHistory" → install, then restart. Or clone into ComfyUI/custom_nodes:

cd ComfyUI/custom_nodes
git clone https://github.com/system-out-cho/displayHistory_ComfyUI

No dependencies beyond what ComfyUI already ships (PromptServer, aiohttp, torch), no model files, no requirements.txt. Low risk to install - just don't wire this node into a real workflow and hit run.