cowork-to-code-bridge — let a sandboxed smolagent run work on your real machine, over a shared directory instead of a socket

[abhinaykrupa]

smolagents is deliberately small and runs wherever you put it — including inside a sandbox, a CI job, or a hosted notebook where the agent has no access to the machine you actually care about. I kept hitting the same wall: the agent could reason about my repo perfectly well, but couldn't run the test suite, hit the local Docker daemon, or push a branch, because none of that existed in the sandbox.

So I built cowork-to-code-bridge — an async, file-based RPC bridge that lets a sandboxed agent hand work to Claude Code running on your own machine.

How it works. There is no listener and no open port. The sandbox and the host share one bind-mounted directory. The agent writes a task JSON into it; a daemon on the host picks it up, runs it, and writes the result back. That's the whole protocol.

The reason it's shaped that way: a socket or a tunnel means something on your laptop is accepting connections, which is a real attack surface for a convenience feature. A shared directory means the only thing crossing the boundary is a file you can read before and after. It also survives reboots and sandbox restarts for free — the queue is just files on disk.

Where it fits a smolagents tool. The client is pure stdlib, single-file, and non-blocking, so it drops into a @tool without adding a dependency:

from cowork_to_code_bridge import queue_task, poll_task_result

task_id = queue_task(
    "run pytest and summarize the failures",
    idempotency_key="test-run-1",
    max_budget_usd=1.00,
    permission_scope="readonly",
)
result = poll_task_result(task_id)   # idempotent; poll from anywhere

queue_task returns immediately, which matters for agent loops — a blocking call that takes four minutes to build a Docker image will blow past most agent step timeouts. poll_task_result is idempotent, so a retried step doesn't re-run the work.

The parts that took the longest, in case they're useful regardless of this project:

• Per-task permission scope. Letting a caller pass arbitrary CLI flags means the bridge token effectively grants full shell. Instead the caller picks from a fixed allowlist — plan, readonly, edit, full — each mapping to a vetted flag set. The machine's owner can always override; the caller can only ever tighten.
• Expiry separate from timeout. timeout bounds how long a task runs; max_age_sec bounds how long it may wait. If your laptop was asleep, you do not want a two-hour-old backlog of "deploy" tasks all firing at once on wake. Past the age limit the daemon skips execution and returns a normal result with a distinct exit code.
• Secret redaction on the write path. Task output lands in files on disk, so scrubbing at read time is too late. The daemon redacts before writing — the result file, the progress log, and the status line. Best-effort by construction, and documented as such rather than oversold.

Runs on macOS and Linux. MIT. Genuinely interested in whether the file-queue-instead-of-a-socket tradeoff holds up for other people's setups, or whether there's a failure mode I haven't hit yet.