cowork-to-code-bridge — running work on a developer's own machine from a server-side Flowise instance, with no inbound port

[abhinaykrupa]

Flowise runs as a server — Docker, a VPS, Render, someone's homelab box. That placement is the whole point for a team tool, but it also means a chatflow's Custom Tool node executes wherever Flowise lives, not where the developer's work lives. If the answer to a request is "run the test suite on my laptop and tell me what broke," there is no node for that, and the usual fixes are heavy: expose the dev machine over a tunnel, run an agent on it that polls an API, or give Flowise SSH credentials into a workstation.

I built cowork-to-code-bridge for the narrow version of that problem — letting a sandboxed or server-side caller run work on a specific developer machine, with no inbound port on that machine.

https://github.com/abhinaykrupa/cowork-to-code-bridge

The mechanism is deliberately dull. A shared directory (bind mount, syncthing, whatever you already trust) holds commands/, results/, cancel/. The caller writes a JSON command file; a daemon on the target machine polls, runs an allowlisted script, writes a JSON result. No listener, no tunnel, no open port, no credentials handed to the server. The machine only ever makes outbound moves. It survives reboots and laptop sleep because "unreachable" and "hasn't picked it up yet" are the same state.

Where it fits a Flowise graph: a Custom Tool that writes the command file and returns a task_id immediately, and a second tool that polls it. That shape matters more than it sounds — the thing I'd flag to anyone wiring long work into a chatflow is that you should not hold a tool invocation open for a 20-minute build. Queue and poll as two separate ops, so the chatflow can answer "still running, 6 minutes in" instead of blocking a socket until something times out.

Four things that turned out to be load-bearing, and I think they generalize to any Flowise node that delegates to a long-running external runtime:

1. Waiting and running need separate bounds. A timeout limits execution. It does nothing for a task that sat in the queue four hours because the target machine was asleep — and then executes on wake, long after the user gave up. For a "deploy" or "push," running that late is worse than never running. So max_age_sec bounds the wait independently, and the age check fails open on a missing timestamp so older callers don't break.
2. Cancel has to kill the process group. SIGTERM to the direct child orphans the actual build tree. Group-kill, SIGKILL after a grace period, then write a normal result record with a distinct code — the caller shouldn't need a special code path to notice "cancelled."
3. Output is unbounded and untrusted. Anything the run prints lands on disk. stdout/stderr are capped while streaming (keep the tail, and flag the truncation explicitly, so absence of the flag means nothing was dropped), and secrets are scrubbed on the write path — the result file, progress log, and status line are three separate sinks and all three need it. Best-effort, not a guarantee.
4. Idempotency keys beat retries. For state-changing delegated work, the failure mode isn't a dropped call, it's a retry that double-fires a push.

Honest scope. This is plumbing, not an agent framework — it ships no model and no agent loop, and it competes with nothing in Flowise. It assumes you can put one shared directory between the two sides; if you can't, this is the wrong tool. And it only executes scripts you explicitly allowlist on the target machine, which is a real constraint, not a limitation I'm apologizing for — the alternative is handing a server arbitrary shell on a workstation.

MIT, Mac and Linux. Happy to answer anything about the failure modes — those are the interesting part.