DEV Community: Suresh Pegadapelli

How I Connected Claude Cowork to My Local Machine

Suresh Pegadapelli — Wed, 29 Jul 2026 14:46:18 +0000

I've been using Claude Cowork a lot, and it has genuinely changed how I work.

It can understand my project, edit files, suggest improvements, and even help me debug problems.

But I kept running into one limitation.

Every time Cowork asked me to run tests, start a development server, install dependencies, or push code to GitHub, I had to stop what I was doing, switch to my terminal, run the command, and then copy the output back into the chat.

After doing this over and over again, I started thinking...

"What if Cowork could safely ask my own machine to do those tasks instead?"

That idea became "cowork-to-code-bridge".

The bridge runs as a small background process on my Mac or Linux machine. Instead of opening network ports or exposing a web server, it simply watches a shared folder for tasks from Cowork. When a new task appears, it runs it locally and sends the result back to the same conversation.

I wanted to keep the design as simple and secure as possible.

A few things that were important to me:

It only runs scripts that I've explicitly approved.
If I want, it can pause and ask for confirmation before running sensitive actions like deployments.
It includes per-task cost limits so an AI mistake doesn't lead to unexpected API costs.
If the same task is retried, it returns the previous result instead of running commands like git push twice.

Getting started only takes a minute.

curl -fsSL https://raw.githubusercontent.com/abhinaykrupa/cowork-to-code-bridge/main/install.sh | bash

Then simply ask Cowork to set up the bridge.

The project is still in its early stages (v0.5.x), so I'm much more interested in feedback than stars.

If you try it, I'd really like to know:

What worked well?
What didn't?
What would make it more useful for your workflow?

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

5 Things I Learned Building My First AI Developer Tool

Suresh Pegadapelli — Tue, 28 Jul 2026 11:59:36 +0000

5 Things I Learned Building My First AI Developer Tool

When I started building cowork-to-code-bridge, I thought the hard part would be writing the code.

I was wrong.

The real challenge wasn't Python, file handling, or process management—it was making the tool secure, reliable, and simple enough that I'd actually trust it on my own machine.

Looking back, here are five lessons I learned during the journey.

My first idea wasn't the best idea

Like many developers, my first instinct was to use a web server.

It seemed obvious. Claude sends a request, a local server receives it, executes the task, and sends the response back.

The more I thought about it, the more problems I discovered.

Opening ports, authentication, firewall rules, and keeping another service running all added complexity for something that should have been simple.

Eventually, I stepped back and asked myself:

"What's the simplest way for two processes on the same machine to communicate?"

That question led me to a file-based bridge, and the design became much simpler.

Security became more important than convenience

At first, I focused on making the project work.

Later I realized the more important question was:

"Would I actually trust this running on my own laptop?"

That changed how I approached the project.

Instead of allowing arbitrary execution, I limited the bridge to approved scripts and authenticated requests with a bridge token.

Removing unnecessary access made the design much easier to reason about.

Building features is easy. Building trust is harder.

As developers, we enjoy adding features.

Run Docker.

Check Git.

Execute commands.

Build projects.

But none of those features matter if users don't trust the software.

I found myself spending more time thinking about failure cases and edge cases than adding new functionality.

That wasn't something I expected when I started.

Good documentation is part of the product

I underestimated how much time I'd spend on the README.

Writing code is only half the job.

If someone can't understand what the project does within the first minute, they're unlikely to try it.

Improving documentation became just as important as improving the code itself.

Shipping early taught me more than waiting

There were plenty of things I wanted to polish before sharing the project.

But eventually I realized I'd learn far more from real feedback than from endlessly refining it in private.

Publishing early has already given me new ideas and different perspectives on the design.

Final Thoughts

This project is still evolving, and I'm sure there are more lessons ahead.

One of the reasons I enjoy open source is that every discussion, issue, and pull request teaches me something I probably wouldn't have discovered on my own.

If you're building AI developer tools yourself, I'd genuinely love to hear what design decisions you would have made differently.

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

I Got Tired of Copying Commands Between Claude and My Terminal, So I Built a Bridge.

Suresh Pegadapelli — Mon, 27 Jul 2026 08:34:51 +0000

Like many developers, I've been spending a lot of time using Claude to help me write code.

It's incredibly good at explaining ideas, reviewing pull requests, and generating code. But every time I wanted it to actually do something on my machine, I found myself stuck in the same loop.

I'd ask Claude to build a small FastAPI project.

Claude would generate the code and then say something like:

"Run these commands in your terminal."

So I'd switch to Terminal.

Copy the commands.

Run them.

Wait for an error.

Copy the error.

Come back to Claude.

Paste it.

Wait for another response.

Repeat.

After a while, I realized I wasn't really working with AI anymore—I was acting as the messenger between Claude and my own computer.

That got me thinking.

"Why can't Claude simply ask my computer to do the work?"

Not by opening ports to the internet.

Not by exposing SSH.

Not by installing another server.

Just... safely.

That idea eventually became cowork-to-code-bridge.

The problem I wanted to solve

Claude Cowork is intentionally sandboxed. That's a good thing.

It can't access my terminal, local repositories, Docker containers, or files outside the mounted workspace.

From a security perspective, that makes perfect sense.

But as a developer, it also means there's a gap between planning and execution.

Claude can tell me exactly what to do, but I still have to perform every step manually.

For small tasks that's fine.

For larger tasks—running tests, installing dependencies, fixing build failures, checking logs, or starting services—it becomes repetitive very quickly.

I wanted to remove that friction without compromising security.

My first thought was...

"Why not just use a web server?"

The more I thought about it, the less I liked the idea.

Opening ports.

Managing certificates.

Authentication.

Firewalls.

Keeping another service running.

It felt like solving one problem by creating three new ones.

So I took a different approach.

Instead of networking, I used something much simpler: a shared folder.

Claude writes a task into the bridge folder.

A lightweight daemon running on my machine notices the task, executes an approved script (or hands it off to Claude Code), and writes the result back.

No inbound ports.

No web server.

No SSH.

Just a simple handoff using the filesystem.

Security was more important than convenience

The biggest question people ask is:

"Isn't giving an AI access to your machine dangerous?"

That's exactly the question I asked myself while building it.

So I tried to keep the design intentionally conservative.

The bridge doesn't expose any network ports.

It never runs with elevated privileges.

Only approved scripts can be executed.

Every request is authenticated using a bridge token.

It also keeps track of completed requests, so if a connection drops and the same request is sent again, it won't accidentally execute the task twice.

I wanted something I would actually feel comfortable running on my own laptop every day.

What can it actually do?

Once it's connected, I can ask Claude to do things that previously required switching back and forth between the browser and my terminal.

For example:

Build a FastAPI project locally.
Run the test suite and report failures.
Install missing dependencies.
Check Docker containers.
Inspect disk usage.
Review a Git repository before pushing changes.

Instead of telling me how to do those things, Claude delegates the work to Claude Code running on my own machine and sends the results back into the conversation.

Why I decided to open-source it

I originally built this for myself.

After using it for a while, I realized other developers were running into exactly the same problem.

Most of us don't need AI to write another function.

We need AI to help with the repetitive work around software development.

If this project saves someone a few minutes every day—or inspires a better approach—then publishing it was worth it.

I'm still actively improving the project, so feedback is genuinely welcome.

If you think the idea is interesting, I'd really appreciate a Star on GitHub. Stars help more developers discover the project, and every issue, discussion, or pull request helps make it better.

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

Bridge the Gap Between Cowork and Claude Code with Human Approval Loops

Suresh Pegadapelli — Mon, 20 Jul 2026 09:23:09 +0000

If you've ever used Claude Code on your local machine while chatting with "Cowork", you've probably noticed something frustrating.

The two experiences are completely separate.

Claude Code is running on your Mac, waiting for terminal input whenever it needs approval. Meanwhile, you're having the conversation somewhere else.

That disconnect inspired me to build cowork-to-code-bridge.

The goal is simple:

Let Claude Code ask for approval directly inside Cowork, then continue running after receiving your answer.

No tunnels. No servers. No custom infrastructure.

The Problem

Imagine asking Claude Code to deploy an application.

Run the tests.

If everything passes,
ask me before deploying.

Eventually Claude Code reaches the deployment step and waits for confirmation.

Ready to deploy?
[y/n]

The problem is that the prompt appears inside your terminal.

Now you have to:

Keep watching the terminal
Switch away from Cowork
Type your answer
Return to your conversation

For long-running tasks this quickly becomes annoying.

It also becomes risky.

Many AI-assisted workflows run unattended for long periods, consuming tokens or making changes without another checkpoint.

I wanted a simpler workflow.

The Idea

Instead of asking for approval in the terminal, why not ask inside Cowork?

The conversation becomes something like this.

You:
Deploy if tests pass.

Claude Code:
Tests passed.
Deploy to production?

You:
Yes

Claude Code:
Deployment completed.


Everything stays inside one conversation.

---

# How the Bridge Works

The bridge is intentionally simple.

Instead of opening ports or exposing an API, both sides communicate through a shared directory using JSON files.

Cowork
│
▼
queue/
results/
to_cowork/
cowork_results/
▲
│
Mac Daemon
│
▼
Claude Code

The flow looks like this:

Cowork writes a task into the queue.
A lightweight daemon running on your Mac picks it up.
Claude Code executes the task.
If approval is required, the daemon writes a request back.
Cowork displays the question.
You answer.
Claude Code resumes execution.
The final result is returned.

Since everything is file-based:

no HTTP server
no SSH tunnel
no cloud infrastructure
no open ports

Example

Here's what the workflow looks like from Python.

from bridge_client import (
call_remote_streaming,
reply_to_machine,
resume_remote,
)

result = call_remote_streaming(
"scripts/run_claude.sh",
args=[
"Run tests then ask before deployment",
"/Users/you/project"
],
interactive=True,
timeout=600,
)

while result.get("state") == "awaiting_reply":
print(result["question"])

reply_to_machine(
    result["request_id"],
    "yes"
)

result = resume_remote(
    result["cmd_id"],
    result["_deadline"]
)

print(result["stdout"])

The approval step becomes part of the conversation instead of interrupting your workflow.

Features

Human Approval Loops

Claude Code can pause whenever it needs confirmation.

Examples include:

Deployments
Database changes
Large refactors
Security-sensitive actions

Cost Limits

You can define a maximum budget for each task.

call_remote_streaming(
"scripts/run_claude.sh",
args=["Refactor project"],
max_budget_usd=2.00,
)


If the budget is reached, execution stops.

This helps avoid unexpected token costs.

---

## Permission Scopes

Not every task needs full access.

You can run Claude Code with different permission levels.

python
call_remote(
"scripts/run_claude.sh",
args=["Analyze repository"],
permission_scope="plan",
)




This makes it easier to share AI tooling without giving unrestricted access.

---

## Interactive Debugging

Sometimes Claude Code discovers missing information halfway through a task.

Instead of failing immediately, it can ask.

Need AWS credentials.
Continue?

You respond in Cowork and execution resumes.

# Why I Chose a File-Based Design

There are plenty of ways to build remote communication.

I deliberately chose files because they provide several advantages.

* Easy to debug
* No networking configuration
* Works offline
* Atomic writes
* Simple deployment
* Platform-independent

Sometimes the simplest architecture is the easiest to maintain.

# Current Status

The project currently supports:

* Interactive approval loops
* Live execution status
* Cost limits
* Permission scopes
* Idempotent task execution
* Model selection
* Open-source implementation

I'm also working on easier installation through Homebrew and PyPI.

# Getting Started

Install the daemon on your Mac.

curl -fsSL https://raw.githubusercontent.com/abhinaykrupa/cowork-to-code-bridge/main/install.sh | bash

Then call it from Cowork.

from bridge_client import call_remote_streaming

result = call_remote_streaming(
    "scripts/run_claude.sh",
    args=[
        "Do something useful",
        "/path/to/project"
    ],
    interactive=True,
)


That's all that's required to start experimenting with approval-driven workflows.

# Final Thoughts

Large language models continue to improve, but safe automation still depends on


![ ](https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/8bhkzdnq33l4mlw2hevw.png) good guardrails.

Approval checkpoints, budget limits, and permission controls are just as important as the model itself.

This project is my attempt to make those guardrails easier to use without adding unnecessary infrastructure.

If you're experimenting with Cowork and Claude Code together, I'd love to hear your feedback.

## Project Links

* GitHub: https://github.com/abhinaykrupa/cowork-to-code-bridge
* Documentation: https://github.com/abhinaykrupa/cowork-to-code-bridge#readme

Demo Video: https://youtu.be/IkzxMxVpKTk

If you find the project useful, consider starring the repository or opening an issue with ideas for improvement.

Connect Claude Cowork to Your Local Machine — Install + Live Demo

Suresh Pegadapelli — Fri, 12 Jun 2026 08:33:41 +0000

Claude Cowork is great for planning, editing, and chatting — but it runs in a sealed cloud sandbox. It can't touch your machine. No shell. No repos. No tools.

Claude Code, running locally, can. This bridge connects the two.

One message in Cowork → a real Claude Code agent on your Mac does the work → result streams back to your chat. No copy-pasting commands. No switching windows.