DEV Community

Suresh Pegadapelli
Suresh Pegadapelli

Posted on

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

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

Top comments (0)