← Blog

2026-07-01

The Teammate You Delegate Coding To

I keep a running list of tasks I think of on my phone that never make it into a terminal until hours later. The agent that would actually do the work lives on one specific laptop, in one specific terminal tab, logged into one specific session. By the time I sit back down, half the urgency is gone and I’ve context-switched three times.

That’s the actual problem — not “AI coding agents aren’t good enough.” They’re plenty good. The GitHub description for Claude Code says it plainly:

Claude Code is an agentic coding tool that lives in your terminal, understands your codebase, and helps you code faster…

Lives in your terminal. That’s the feature and the cage in one sentence. Claude Code and Cursor both do real work — I use both daily — but they’re tethered to wherever you happened to open them. If that’s not where you are right now, you wait or you do it yourself, which defeats the point of delegating.

So I built Shraga. The name is Hebrew for a small lamp — the kind you keep lit to find your way in the dark. This one points at a machine that’s already running.

Where it sits in the landscape

There’s already a well-funded answer to “delegate a task, get a PR back”: Devin, Cognition’s autonomous agent. It spins up its own sandboxed cloud environment — shell, editor, browser — and works asynchronously from a Slack message or a Linear ticket. It’s genuinely impressive, and it’s the exact opposite of what I wanted.

Devin Claude Code / Cursor Shraga
Runs on Vendor cloud Your laptop, one session A machine you own
Reachable from anywhere ✅ ❌ tethered ✅
Your git tokens / diffs stay yours ❌ vendor holds them ✅ ✅
Locked to one runtime ✅ (their agent) ✅ (that app) ❌ bring your own

Shraga isn’t trying to out-agent Devin. It’s the thin layer that makes the agent you already trust reachable, without moving your credentials to someone else’s servers.

The design stance

Bring-your-own-runtime. Shraga doesn’t ship its own agent. It forwards the task to whatever runtime is configured on the box — today Claude Code or Cursor, tomorrow whatever earns a place. The runtime is a plug-in, not the product. I don’t want to bet the tool on one vendor winning.

Self-hosted, on purpose. The machine doing the work is one I own — home server, VM, whatever. That’s not a compliance checkbox; it’s the whole point. The repo access and the credentials the agent needs to do anything useful stay on infrastructure I control. A hosted middleman means someone else’s servers hold your git tokens and read your diffs.

Multi-user, because “self-hosted” usually degrades into “single-user script only I can touch.” If I set this up for a small team, I want to hand a teammate access without handing them my machine. That’s most of why this took longer than a weekend hack.

Reachable from anywhere — phone in a cab, a browser on someone else’s laptop, or my actual dev box. The runtime doesn’t care where the request came from; it gets a task and works on the box it lives on.

What it actually is right now

You install it on the machine that has your runtime and your repos:

bunx shraga          # run it on the box with your agent + repos
bunx shraga --help   # see options

It needs Bun >= 1.0. From anywhere else you forward it a task; it picks it up, runs it through Claude Code or Cursor on that machine, and hands back the result — a diff, a PR, a “done, here’s what I changed.” The npm package (shraga, currently 0.0.3) tags itself exactly this way: claude-code, cursor, agent-runner, self-hosted.

Honest about where it isn’t

This is early — a controlled rollout, not a public 1.0. The core loop works: forward a task, runtime picks it up, work happens on your machine. The parts I’m still hardening are the ones that matter most for trusting it with real work: permissioning across multiple users, sandboxing what a delegated task can actually touch, and making failure modes visible instead of silent. A self-hosted agent runner with weak isolation is a liability, not a convenience — so I’d rather ship that slowly and correctly. If you request access today, you’re getting the loop, not the finished multi-tenant story.

The bet underneath all of it: “delegating to an agent” should stop being synonymous with “opening a terminal on this laptop.” Once the agent is reachable instead of tethered, you delegate the way you would to a person — from wherever you are, to whatever runtime is best positioned — on infrastructure you actually trust, because it’s yours.

If that’s a problem you’ve felt too, the repo is github.com/Livshitz/shraga, and access is opening up gradually — join the waitlist at livx.cc/shraga.

Here’s the question I keep circling: when you delegate a coding task remotely, where do you actually want it to run — someone else’s cloud, or your own box you can reach from your phone?

References