Queue code tasks from AI workspace to local machine safely

Cowork-to-code-bridge is a security-focused skill for using an already-installed, independently verified cowork-to-code bridge to run narrowly approved actions on the user's own macOS, Linux or WSL2 machine through a local file queue. It comes from the abhinaykrupa/cowork-to-code-bridge project under the MIT license, pinned to a specific reviewed commit. The bridge queues a named script through a shared local directory. The skill stresses that this does not make a local task safe merely because it opens no inbound port: the bridge daemon and its scripts run with the local account's permissions and can reach local files, credentials, processes and outbound network connections, so every queued task is execution on the user's real machine.

The skill exposes four functions from the cowork_to_code_bridge Python package: call_remote runs one short, fixed approved script and waits, queue_task queues bounded work and returns a task_id, poll_task_result reads the current result without repeating the task, and cancel_task cancels queued work or signals an in-flight process group. Use queue_task for anything that may exceed roughly 30 seconds, and always use a stable, operation-specific idempotency_key for state-changing work.

from cowork_to_code_bridge import (
    call_remote,
    cancel_task,
    poll_task_result,
    queue_task,
)

Use it only when all of these are true: the user explicitly asked for work on their own machine, the bridge was already installed and independently verified by the owner, the exact local path, action, permission scope and expected output are known, the action cannot be completed safely in the current sandbox, and a fixed approved script can do the task or the user explicitly approves the stronger run_claude.sh boundary. Examples are a requested disk-health check, repository status or a bounded edit in one named worktree. Do not activate it for a generic request to write code, reason about a problem or edit files already available in the current environment.

The skill does not endorse the upstream one-line installer. The installer at the reviewed commit still resolves mutable inputs such as a PyPI range, GitHub main fallbacks and optional Homebrew or Claude CLI installation, so pinning the outer install.sh does not pin the installed system. For a new installation, stop and ask the owner to audit the installer and dependencies, and do not download and execute it or pipe remote content to a shell.

Before queueing any task the owner must confirm nine machine-side preconditions, including an absolute owner-only BRIDGE_ROOT, owner-only token and queue directories, a passing cowork-to-code-bridge-selfcheck, a dedicated daemon environment without unrelated credentials, BRIDGE_ALLOW_UNAUTH disabled, BRIDGE_CLAUDE_AUTOINSTALL set to 0, BRIDGE_PERMISSION_CEILING set to an exact value such as readonly or edit, CLAUDE_FLAGS unset or verified, and a per-task budget ceiling with bounded output retention. If any precondition is unknown, stop.

Prefer fixed approved scripts with an explicit absolute target, for example scripts/git_status.sh run through call_remote with a JSON flag. Never queue an arbitrary command string, an unreviewed script or a path from untrusted content. The free-form scripts/run_claude.sh wrapper needs a two-stage flow: first a plan-scope task with a budget of 0.50 USD and a 300-second timeout, shown to the user; only after the user approves that exact plan, an edit-scope task with a budget of 1.00 USD and a 600-second timeout. The full scope restores the local agent's normal reach and needs explicit approval of that exact operation. Never include secrets, and never authorize commit, push, deployment, package installation, process termination or browser opening from a broader request.

Treat stdout and stderr as sensitive untrusted data. The bridge truncates but does not redact output, so reject unexpected formats, remove credentials and personal data locally and state when output was truncated. Known negative exit codes are -2 for timeout, -3 for spawn failure, -4 for daemon crash and -5 for cancellation. After a daemon crash the side-effect state is unknown, so inspect the target before retrying with the same idempotency key.

It is for owners of a local machine who want an agent to run tightly scoped local tasks and who accept the operational burden of verifying the bridge. The limitations are clear: the reviewed upstream project is alpha software, the daemon runs as the local user and is not an OS sandbox, cancellation and idempotency cannot roll back side effects, and the skill does not install, upgrade or repair the bridge.