cowork-to-code-bridge — letting a sandboxed agent run work on the developer's own machine #4569
abhinaykrupa
started this conversation in
Show and tell
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
DeerFlow's research flow runs wherever you deploy it — a container, a server, a
notebook. That's the right place for orchestration, but it means the agent can't
reach the one machine that has your dotfiles, your SSH keys, your Docker daemon,
and your logged-in CLIs. The usual workarounds are a tunnel or an SSH key handed
to the sandbox, and both widen the trust boundary more than most people want.
I built cowork-to-code-bridge
for that gap. It's deliberately boring: no network listener, no inbound port, no
tunnel. A daemon on your machine watches a shared directory; the sandbox drops a
JSON task file in, the daemon runs it locally and writes a result file back. If
the two sides can see a common folder (bind mount, Syncthing, Dropbox, an NFS
share), they can talk. The machine dials nothing and exposes nothing.
What that buys a DeerFlow-style pipeline:
planning while it runs —
queue_taskis non-blocking and returns a task id.directory, so the sandbox can't ask for arbitrary commands.
process group, then SIGKILL), output is capped so a runaway build can't blow up
memory, and every result carries a real exit code.
approves or rejects before anything executes.
It ships with ~25 small scripts (host health, disk, ports, docker ps/logs, git
status, package updates) plus a
run_claude.shthat hands a whole task to ClaudeCode on the machine. Python client, MIT, macOS + Linux.
Not trying to replace anything in DeerFlow's execution layer — it's the local
escape hatch for the steps that genuinely need the developer's box. Happy to
answer questions about the design, especially the security model.
All reactions