cowork-to-code-bridge — async bridge for Semantic Kernel agents to delegate work to Claude Code on the local machine

[abhinaykrupa]

Show and Tell: cowork-to-code-bridge — give your SK agents a secure async tunnel to your local machine

Hey Semantic Kernel community,

One pattern I run into constantly: an SK agent or planner runs in a cloud container, but the tools it needs — running scripts, accessing local files, calling a GPU model — only exist on my developer machine. Rather than open a port or share credentials, I built cowork-to-code-bridge: an async, file-based RPC bridge that lets a sandboxed SK agent queue work for Claude Code running locally and collect results safely.

Wrapping it as a Semantic Kernel plugin

import semantic_kernel as sk
from semantic_kernel.functions import kernel_function
from cowork_to_code_bridge.client import queue_task, poll_task_result

class LocalCodeExecutionPlugin:
    """SK plugin that delegates code execution to the local Claude Code daemon."""

    @kernel_function(
        name="run_local_script",
        description="Queue a script to run on the local machine and return its output.",
    )
    def run_local_script(self, script_name: str, args: str = "") -> str:
        # Queue without blocking — SK planner can parallelize across plugins
        task_id = queue_task(
            tool="bash",
            args={"command": f"python {script_name} {args}"},
            idempotency_key=f"sk-{script_name}-{hash(args)}",
        )

        # Poll until the local daemon finishes
        result = poll_task_result(task_id, timeout=180)
        if result["status"] != "success":
            return f"ERROR: {result.get('error', 'unknown failure')}"

        metrics = result.get("metrics", {})
        return (
            result["output"]["stdout"] + "\n"
            + f"[bridge: {metrics.get('latency_ms', '?')}ms, "
            + f"cost ${metrics.get('cost_usd', 0):.4f}]"
        )

Register it with your kernel and any planner — FunctionCallingStepwisePlanner, HandlebarsPlanner, etc. — will discover and call it automatically.

What the bridge provides

Feature	Detail
queue_task / poll_task_result	Async dispatch; SK planners can fan out multiple tasks
Loop detection	Catches agent retry storms before they spiral
Per-op metrics	Per-task latency and token cost surfaced in results
Budget cap	Hard ceiling on total spend across a planning session
No open ports	File-based transport; no network config or firewall rules

Why this matters for SK

Semantic Kernel's auto-planning is powerful, but it can call the same plugin dozens of times in a retry loop — that's exactly what the loop-detection and budget-cap features were designed for. And the idempotency key means a replanned step won't double-execute a side-effectful local operation.

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

---

Question for the SK community: Are you running SK agents in environments where they can't directly reach your local tools? What's your current pattern for bridging that gap — native plugin with a REST endpoint, SSH tunnel, something else?