DEV Community: GetPullRequest

Ship code from your phone with the AI coding agents you already pay for

Hari N — Tue, 06 Oct 2026 11:31:34 +0000

We run AI coding agents like Cursor, Claude Code and Codex from our phones. The agents don't run in a vendor's cloud sandbox. They run on our own laptops, and each of us has also paired a cloud desktop as a second machine. The phone is how we give them work and check on them. The tool that does this is GetPullRequest (GPR), and we have been building GPR with GPR since May. Every branch a GPR task or session creates is named gpr/task-tsk_…, and by now that is most of our branch list.

TL;DR: GPR runs the AI coding agents you already pay for (Cursor, Claude Code, Codex and five more) on your own machine, using the Agent Client Protocol. Tasks can come from the app, GitHub, GitLab, Jira or Slack. You answer the agent's questions and merge its pull request from your phone. Your machine needs to be on.

This post covers how a task runs, why we keep the agent on your machine, and some of the strange problems we ran into while building it. If you want the story of why we built GPR in the first place, read the launch post.

Claude Code remote control, Codex, Cursor background agents: why not just use those?

It's a fair question. Claude Code has Remote Control, Codex works with the ChatGPT app, and Cursor has background agents (now called Cloud Agents) that you can start from Slack or their iOS app. If you only use one agent and just want to check on one session from your phone, those tools are good and you should use them.

The problem is that each one is a chat with a single vendor's agent. Claude Code's Remote Control, for example, only works with Anthropic's models and a claude.ai login. If you run Claude Code with an API key or through OpenRouter, Remote Control won't start. Our team was using four different agents, and nobody wanted to switch to just one. Our work also didn't start as a chat. It came in as GitHub issues, Jira tickets from the product team, and screenshots posted in Slack. What we wanted was an assistant for every developer that owns a task board, keeps track of the work on it, and gets it done with whichever agent fits.

How a task actually runs

You create a task on the board in the app. It can also come from a GitHub issue with the gpr:agent label, from a Jira project, or from an @gpr mention in Slack. The task goes to the workspace where you ran gpr setup.

The GPR daemon on that machine picks up the task and creates a git worktree for it under ~/.gpr/worktrees/. This keeps the agent away from the branch you are working on. The daemon then starts the agent you chose for that workspace, and the agent plans, implements, verifies, writes a commit summary and opens a pull request. GPR saves a checkpoint after each step, so if something interrupts the run, it continues from the last checkpoint instead of starting again.

If the agent has a question while it is planning, the task moves to "Needs your input" and you get a notification on your phone. You reply on the task and the agent continues. When the pull request is open, the task stays in "In review" until it is merged. You can also open the live session at any time and watch what the agent is doing.

None of this is complicated on paper. Most of our time went into making it work reliably on real laptops, real networks and with real agents.

Why AI coding agents should run on your machine: faster, and already paid for

Our repo is an Nx monorepo with a FastAPI backend, a Flutter app, a Go daemon, a generated Dart SDK and a couple of other products. Building it from a fresh checkout takes quite a few steps.

We tried hosted sandboxes first, using Daytona. The first problem was setup. We had to get the backend, the Flutter app, the database and the daemon running together inside a sandbox, and keep them working as the code changed. The second problem was cost , which was hard to justify for a startup when our laptops were sitting idle half the day. The biggest problem was testing. Every time we wanted to check an agent's change, someone had to check out the branch and build everything from scratch.

"We were paying to rebuild an environment in the cloud that was already fully built on the laptop in front of us."

When the agent runs on your machine, it runs the tests the same way you do. Your code, your agent's login and your API keys stay on your machine. The GPR backend only holds the board and the task queue, passes the session to your phone and sends notifications. It never has a copy of your repo.

The downside is that your machine has to be on. If your laptop goes to sleep, the task waits as "Waiting for machine" and continues when the laptop wakes up. That's why each of us also paired a cloud desktop.

Everything works with nothing connected

Our first plan was to get diffs and merge status from GitHub. We dropped it before writing any code. The agent's changes are on your machine, often not even committed yet, so GitHub doesn't know about them. GPR reads them with git on your machine instead. If you connect GitHub, it adds a bit extra, like whether the PR can be merged or is behind the base branch.

This became a rule for the whole product, and we call it the enrichment model. Coding, reviewing, merge checks, resolving conflicts and changing a task's base branch all work using the daemon and git on your machine. Integrations bring work in and handle things like opening the pull request on GitHub. They never replace information your machine already has.

Works with nothing connected	Added when you connect a provider
Coding, plan/implement/verify	Issues synced in from GitHub, GitLab or Jira
Diffs and merge checks from local git	"Mergeable" and "behind" hints from GitHub
Resolving conflicts, changing base branch	Opening the hosted PR
The board, queue, live session and @gpr mentions	Tasks started from Slack

In the code, each provider lives in its own folder and plugs into a shared interface. We added GitHub first, then GitLab (which mostly copied the GitHub structure), then Jira and Slack. In August we found GitHub-specific code in places that were supposed to work for every provider, and we spent some time cleaning that up. It still isn't perfect.

This approach helped us in September. Atlassian removed an old Jira search endpoint, and our Jira calls started failing with 410 Gone. The agents kept working as normal. Only the syncing of new tickets stopped. We wrote the fix up as a Jira ticket, and GPR picked it up and opened the pull request.

Some weird issues we hit while building it

I want to share a few of these because building reliable software takes time, even when agents write a lot of the code. In most cases, finding the problem took much longer than fixing it.

The connection that was dead on one side.

A Windows machine had a connection that looked fine from the machine's side, but the relay could not reach it. The daemon thought it was online, so it never reconnected. Tasks sent to that machine just waited and nothing happened.

Split brain after a deploy.

When we deploy a new version of the backend, the old servers keep running for a short time before they shut down. The daemon's live connection stayed on one of those old servers, while its normal API calls went to the new ones. So one part of the backend thought the machine was connected, and another part thought it was not. We fixed both problems the same way: the backend now starts the reconnect itself, and the daemon checks its status regularly and reconnects if the two don't agree.

52 agents on one laptop.

In August one developer's machine had 52 agent processes running, each using about 300 MB of memory, a few minutes after the daemon started. Several Cursor agents had started at the same time and were all trying to use the same config file, so their startup failed. We retried, but the failed agents did not stop when we asked them to. We had also stopped tracking them, so nothing ever cleaned them up. Now we give an agent two seconds to stop, and if it is still running, we kill it.

Tasks marked done with no changes.

Sometimes an agent said it was done and wrote a good summary, but it had not changed any code. GPR still marked the task as successful. Now a task with no commits is marked as failed. In another case, a log line that should have explained why tasks were timing out printed nothing useful, because it used Go formatting in Python code. When we fixed the log, it showed us a second bug where one session could start two agents. Both stories are in AI can run the software factory. It can't turn the lights off yet.

Updates on Windows.

On some Windows machines gpr update did nothing, but the output looked the same as a successful update. Windows does not let you replace a program while it is running, but it does let you rename it. So now we rename the old program and put the new one in its place. Every change to the daemon has to work on macOS, Linux and Windows, and Windows caused most of these problems.

Duplicate Slack messages.

Slack sends us every @gpr mention twice, but only one of the two has the screenshot attached. We were reading the other one, so screenshots people attached to bug reports were lost.

You may have noticed that several of these problems came from the agents themselves, like the Cursor processes that would not stop. That happens because GPR runs coding agents from existing vendors instead of an agent we built ourselves. We chose that on purpose, early on, and the next section explains why.

Agent Client Protocol: why we never built our own coding agent

Almost every developer we talked to was already paying for a coding agent, whether that was a Cursor plan, a Claude subscription or ChatGPT for Codex. Asking them to pay for another agent just to try GPR would have been a barrier, and they would be paying twice for the same thing. That's also why I find it hard to justify paying for Devin on top of those plans.

What we didn't know was how to support all of these agents without building a separate integration for each one. Then I watched a video with Ben Brandt from Zed and people from JetBrains about the Agent Client Protocol (ACP). Without a shared protocol, every editor needs its own integration with every agent. With ACP, each editor and each agent only has to support the protocol once.

If Zed and JetBrains were building this standard for editors, a phone app could use it too.

Here is how GPR uses it. The daemon talks to the agent using ACP on your machine. The daemon also connects out to our relay over a WebSocket, and the relay sends the same messages on to your phone. The relay keeps a copy of the session, so if your phone goes offline it can catch up later, and it sends you a notification when the agent needs you. Because of this, the app doesn't have to read a terminal screen. It receives the plan, tool calls, diffs and the agent's slash commands as structured data, which is why one app works with every agent.

Cursor and Kiro support ACP directly, so they were the first agents we fully supported, in July. Claude Code and Codex need an adapter, and we added them in September. Today the daemon supports eight agents: Cursor, Claude Code, Codex, Kiro, OpenCode, Qwen, Cline and Copilot. Our ACP post explains the protocol in more detail, including how it differs from MCP.

We built GPR using Cursor, Claude Code, Kiro and OpenCode, and nobody on the team had to give up the agent they liked. 370 commits in our repo are co-authored by GPR. Each agent starts up, logs in and shuts down a little differently, and the daemon handles those differences. Switching agents is just a dropdown in the app.

What a phone is actually good for (the Claude Code mobile app question)

A lot of people search for a Claude Code mobile app. In practice, the things you need to do on a phone are fairly small: answer a question about the plan, approve a command, read a short diff, give feedback and merge. On Android you can also share a screenshot from your gallery directly into an agent session, and a lot of our own bug reports now start that way.

We spent a lot of time making these small things easy on a small screen. You can leave a comment on a diff by tapping or long-pressing the line, and the agent picks it up in the next round. Long agent sessions have a conversation minimap, so you can jump to the part you care about instead of scrolling through everything. The slash commands in the app are the ones your agent actually supports, and switching the model or the agent is a single dropdown. When you add reviewers to a pull request, you pick them by name and photo, because nobody remembers GitHub usernames on a phone. If the base branch has moved, you can update the pull request from the phone, and the agent fixes any conflicts in new commits so you can see exactly what it changed. And if your phone loses signal halfway through a session, it catches up from where it left off when it reconnects.

A phone is not the right place to review a big architectural change. When I need to compare big files side by side, still i prefer big screen. But this pushes to keep agent tasks small, and agents do better work on small tasks anyway. You can read more about how we review and merge from the phone. If you're wondering why a person still needs to approve the merge at all, the software factory post covers that in detail.

Still rough

The iOS app isn't in the App Store yet. Live preview of your running app on the phone is still being built. Diffs come from git on your machine, so if your laptop is asleep, you can't see the diff either. And when an agent's login expires, GPR can tell you that the agent failed to start, but someone still has to go to the machine and log in again.

Trying it

To try it, you need the Android app from Google Play (iOS app coming soon), a Mac, Linux or Windows machine, and one coding agent installed on it. GPR is free for projects, sessions, and the GitHub and Slack connections. You pay only for more workspaces or more tasks running at once.

curl -fsSL https://getpullrequest.com/install | bash
cd ~/code/your-repo
gpr setup # scan the QR code with the app
gpr discover # lists which agents are ready

We'd suggest starting with a small task, something you've been putting off, so you can see how it works before giving it anything bigger.

Agent Client Protocol (ACP) is the most important AI coding standard nobody's talking about

Hari N — Tue, 06 Oct 2026 07:10:19 +0000

The Agent Client Protocol is a standard way for a code editor to talk to a coding agent. Zed started it in 2025. JetBrains joined in October 2025 to bring it to IntelliJ and the rest. If an agent speaks ACP, any ACP editor can drive it. If an editor speaks ACP, it gets every ACP agent for free.

We built GetPullRequest (GPR) on it. Slightly odd, because GPR isn't an editor. It's a phone app that runs coding agents on your own machine. Protocol first, then what we did with it.

TL;DR: ACP is to coding agents what LSP was to language tooling. Agents implement it once, clients implement it once. GPR treats your phone as an ACP client and runs eight agents through it: Cursor, Claude Code, Codex, Kiro, OpenCode, Qwen, Cline and Copilot.

The problem the Agent Client Protocol solves

Before ACP, every editor that wanted an agent wrote its own integration, and every agent that wanted to be in an editor did the same backwards. M editors, N agents, M × N bits of glue, each broken in its own way. ACP makes it M + N.

Same trick the Language Server Protocol pulled. It's why your editor can autocomplete Rust without anyone at your editor's company knowing much Rust.

How it works

For a local agent, the client starts the agent as a subprocess and they swap JSON-RPC messages over stdin and stdout. Remote transports over HTTP or WebSocket are still being worked out in the spec. The messages carry what a coding UI needs: the plan, tool calls and their results, file diffs, terminal output, permission requests, slash commands, model choices. Where it can, ACP reuses MCP's JSON shapes, and adds its own types for coding-specific UI like diffs.

The spec and SDKs are at agentclientprotocol.com. Not every agent speaks it natively. Claude Code and Codex get wrapped by small adapter binaries that translate.

In January Zed and JetBrains also launched the ACP Registry: an agent registers once and shows up in every ACP client, installed about the way you'd install an extension. Claude Code, Codex CLI, GitHub Copilot CLI and OpenCode were in it at launch. That's the point where ACP stopped being a Zed thing and started looking like the default.

Agent Client Protocol vs MCP

The names rhyme, so people mix them up.

	ACP	MCP
Connects	A client (editor, phone) to the agent	The agent to tools and data
Typical messages	Plans, diffs, tool calls, permission requests	Tool calls, resources, prompts
Example	Zed or GPR driving Claude Code	Claude Code reading your database

In a normal setup the editor talks ACP to the agent and the agent talks MCP to its tools. You use both.

How we found it

GPR doesn't ship its own coding agent. Nearly every developer already pays for one or two: Cursor, a Claude plan, ChatGPT for Codex, Copilot through work. Making them buy another before they can try GPR is friction, and paying twice. We wanted to reuse what people already have. We just didn't know how without writing and maintaining one integration per agent.

Then we watched a video where Ben Brandt from Zed and people from JetBrains walk through ACP. Our exact problem, solved for editors, and nothing in it required the client to be an editor.

A phone could be just another client.

What GPR does with ACP

GPR's daemon runs on your machine and talks ACP to the agent over stdio, same as Zed would. The daemon dials out to our relay over a WebSocket, so nothing on your machine listens for incoming connections, and the relay passes the same messages on to the app. It keeps the stream, so a phone that dropped off in a lift picks up from the last event it saw, and it sends a push when the agent needs you. So the phone isn't screen-scraping a terminal. It gets plans, tool calls, diffs and terminal output as structured messages, and that's why one mobile UI works for every agent.

The daemon recognises eight today: Cursor (cursor-agent), Claude Code, Codex, Kiro, OpenCode, Qwen, Cline, Copilot. We built GPR with four of them (Cursor, Claude Code, Kiro, OpenCode) and nobody had to agree on one. gpr discover tells you which are ready, which are installed but missing an adapter, which aren't installed. Pick one per workspace. Switch with a dropdown. We don't pull agents from the ACP Registry yet. Anything listed there already speaks the protocol, though, so adding one is a small job for us rather than a new integration.

Some things just fall out of using the protocol properly. The slash commands in the app are whatever the agent advertises over ACP, not a list we maintain, so a new command just shows up. Model switching uses ACP's config options, and if an agent also advertises a models slash command, the app hides it so there's one way to switch everywhere. Agents can send their own extension messages; Cursor and Kiro both do, and they were the first two we supported properly, in July. Not every extension earns its place. In September we hid Kiro's MCP status widget from the chat. It was noise.

Agent Client Protocol with Claude Code

People search for this specifically. Claude Code doesn't speak ACP natively. It goes through an adapter that sits next to the gpr binary, and the installer puts it there. That's also why it was late for us: Cursor and Kiro speak ACP out of the box and got proper support in July, while Claude Code (and Codex) landed on September 18.

The adapter route has one nice side effect. If you run Claude Code on an API key, or through OpenRouter or a company gateway, you set that in GPR's agents.json and it just works. Anthropic's own Remote Control refuses all of those setups. The Claude Code post has the details.

What the protocol doesn't fix

ACP standardises the conversation. It doesn't standardise how agents behave as processes, and running them unattended for hours shows it.

Agents that won't stop. Stop some agents halfway through startup and they ignore the polite signal and keep running. Start several at once and they can trip over the same config file. In August that combination left 52 agent processes on one of our machines, about 300 MB each (the Cursor post has the story). The daemon now gives an agent two seconds to exit, then kills it.

Agents that go quiet. Some stop talking mid-turn without saying why. GPR fails the task after 90 seconds of silence rather than wait forever, so it shows up on your phone as failed instead of sitting at "running" all afternoon.

These tools mostly weren't built to be long-running background processes, and a protocol can't change that. Somebody has to absorb it. For us that's the daemon.

Your keys stay where they are

Your own agent means your own login. Anthropic key, codex login, Cursor account, all stay on your machine, and any keys or gateway settings the daemon needs go in ~/.gpr/agents.json there too (reference). GPR's backend never sees them, and your model bill doesn't change.

Try it

GPR is free for projects, sessions, and the GitHub and Slack connections. You pay only for more workspaces or more tasks running at once. Get the app on Google Play, then:

curl -fsSL https://getpullrequest.com/install | bash
cd ~/code/your-repo && gpr setup
gpr discover

Agent-specific guides: Claude Code, Codex, Cursor. Running several at once across machines: parallel coding agents.

Keep reading

New here? The launch post, Your AI coding agent is stuck in a terminal you have to babysit. So we built GetPullRequest, is the why. The pillar, We ditched cloud AI coding agents. Our laptops were faster, and already paid for, is the how.

Claude Code Remote Control is great. It's also not enough
Codex CLI remote control: stop babysitting the terminal and let it ship PRs while you're out
Cursor background agents charge you twice for compute you already own
Run parallel coding agents on every machine you own, from one phone
AI can run the software factory. It can't turn the lights off yet

Claude Code Remote Control is great. It's also not enough

Hari N — Mon, 05 Oct 2026 15:25:00 +0000

If all you want is to check on a Claude Code session from your phone, use Anthropic's Remote Control. It's built in, it comes with Pro or Max, and for that one job it beats what we make. We sell a competing product. Still true.

The rest of this is how to set Claude Code remote control up, why it sometimes refuses to start, and the point where it stopped being enough for us. That point is where GetPullRequest (GPR) comes in, and it won't be the same point for everyone. The short version: Remote Control is a chat window into one Claude session, running Anthropic's models. GPR is a universal remote for the dev tools you already use, whichever agent, whichever model, wherever the task came from.

TL;DR: Remote Control is a chat with one Claude Code session, on Anthropic's models and a claude.ai login. For that, it's the quicker tool. GPR is a universal remote: Claude Code, Codex, Cursor and five more agents, tasks from GitHub, Jira and Slack, any model or gateway you've configured, and a pull request at the end.

Setting up Claude Code remote control

On the machine where your repo lives:

claude remote-control

That starts a server that waits for your phone. Press space, a QR code shows up, scan it with the Claude app, and you're in the session. Already inside Claude Code? /remote-control, or /rc, does it for the conversation you have open. claude --remote-control starts a normal terminal session that's also reachable from the phone.

Everything still runs on your machine: files, MCP servers, tests. The phone sends messages, can attach a photo or a file, and gets a push when Claude finishes something or needs a decision. Server mode runs several sessions from one process (up to 32 by default), and --spawn worktree gives each new one its own git worktree, which you want if you're starting more than one. It's gotten noticeably better this year. If your laptop sleeps, it reconnects when it wakes.

Claude Code remote control not working?

It's nearly always one of these.

You're on an API key. Remote Control needs a claude.ai subscription login (Pro, Max, Team or Enterprise). ANTHROPIC_API_KEY won't do it, and neither will a token from claude setup-token. Run claude auth login.

You're not talking to Anthropic's API directly. Remote Control isn't available if you run Claude Code through Amazon Bedrock, Google Cloud's Agent Platform or Microsoft Foundry, if ANTHROPIC_BASE_URL points at an LLM gateway or company proxy (unset it), or if you sign in through an enterprise Claude apps gateway. That rules out a lot of companies that buy Claude through their cloud provider.

Your org hasn't turned it on. On Team and Enterprise an owner has to enable it in the Claude Code admin settings. Orgs with Zero Data Retention can't enable it at all, because the transcript syncs through Anthropic's servers.

The process died. Close the terminal and the session goes offline. claude remote-control --continue brings it back for about four hours after that; later than that you start fresh. On a remote box, put it in tmux. In server mode, lose the network for about ten minutes and the process exits.

Anthropic's Remote Control docs cover all of it, and they're good.

Where it stopped being enough for us

Remote Control is a chat app. A good one, but you're talking to one Claude Code session, on Claude models, through Anthropic's own API. We wanted to hand off a task to whichever agent suited it and come back to a pull request.

We build GPR with GPR, and the agents doing that were Cursor, Claude Code, Kiro and OpenCode. Not just Claude. Tasks show up as GitHub issues, Jira tickets, Slack messages. Not as chats we start. Jira ticket PET2-4 became our PR #500 without anyone opening a terminal. Remote Control can't do that; it's one agent and a session you started.

"For a couple of months we used Claude Code in a terminal to build a product that couldn't run Claude Code yet."

That's not a figure of speech. Claude Code wasn't one of the first agents GPR could run. Cursor and Kiro speak the Agent Client Protocol natively, so they got proper support in July. Claude Code doesn't. It needs an adapter sitting between it and any ACP client, and getting that working properly through GPR took us until September 18. Mildly embarrassing, but not really our call.

	Claude Code Remote Control	GPR
Agents	Claude Code	Claude Code, Codex, Cursor and 5 more
Models	Anthropic's Claude models, via Anthropic's API	Whatever each agent supports, including through your own gateway
Where tasks come from	A session you started	App board, GitHub, GitLab, Jira, Slack
Login	claude.ai subscription only	Subscription, API key, or a proxy/gateway via `agents.json`
What it is	A chat with one session	A remote for your whole dev workflow
What you end with	A conversation	A PR you can merge from the phone
Machine has to be on	Yes	Yes

One Claude session and a question to answer from the couch: Remote Control. Six tickets, three agents, each planned, built, tested and turned into a PR: GPR. The API key thing matters more than it sounds if your company pays for Claude through the API and not through claude.ai seats.

Running Claude Code through GPR

Claude Code stays on your machine, in your repo, on your login, API key or gateway. GPR's daemon starts it and talks to it over the Agent Client Protocol, through a small adapter binary. The app shows the session live, buzzes when Claude has a question, and lets you review and merge the PR from your phone.

curl -fsSL https://getpullrequest.com/install | bash
cd ~/code/your-repo
gpr setup

gpr setup registers the folder as a workspace, installs a startup service and prints a QR code. Scan it in the app under Settings → Connections. On Windows it's irm 'https://getpullrequest.com/install.ps1' | iex in PowerShell.

Install the claude CLI and log in. The Claude ACP adapter has to sit next to the gpr binary, and the installer handles that.

On an API key, or going through a proxy or LLM gateway? Put it in ~/.gpr/agents.json rather than exporting it in your terminal. The daemon runs as a background service, so it never sees your shell profile. This one points Claude Code at OpenRouter:

{
  "agents": {
    "claude": {
      "command": "claude-agent-acp",
      "env": {
        "ANTHROPIC_BASE_URL": "https://openrouter.ai/api",
        "ANTHROPIC_AUTH_TOKEN": "sk-or-your-key"
      }
    }
  }
}

Use ANTHROPIC_API_KEY instead for a plain Anthropic key. Keep the command line even though it looks redundant, because env on its own doesn't override the built-in agent. Then gpr restart, since the daemon only reads the file at startup. The agents.json reference has the rest.

That exact setup is one Remote Control refuses. Point Claude Code at OpenRouter, or any gateway, and you lose remote control altogether. Through GPR the phone still works, because GPR never needed Anthropic's relay in the first place.

gpr discover

ready means you're fine. needs adapter means the CLI is there but the adapter isn't next to gpr. not installed means claude isn't on your PATH. Then pick Claude Code in the workspace settings in the app.

Giving Claude a task

Make a task on the board, label a GitHub issue gpr:agent, or mention @gpr in Slack. The daemon makes a worktree under ~/.gpr/worktrees/ so your own checkout isn't touched, runs plan, implement and verify, and opens a PR.

If Claude has a question while planning, the task goes to "Needs your input", the phone buzzes, you answer in a sentence, and it carries on from the checkpoint. One question beats a PR built on a wrong guess.

"Fix the avatar bug" gets you an interpretation. "Settings crashes when avatarUrl is null; show initials; add a widget test" gets you something you can merge. Writing the task is where the actual design happens, which is most of the argument in AI can run the software factory. It can't turn the lights off yet.

Rough edges

Logins expire. When Claude's login runs out, the agent fails to start and GPR marks the task failed and says why. Someone still has to go to the machine and log in. We can't fix that from a phone and aren't sure we should.

Idle sessions get parked. Long Claude sessions sit idle a lot, so after three hours with no activity GPR stops the Claude process to free memory and the next message starts it again.

The machine has to be on. Both tools need it. A phone doesn't change that. That's the point of keeping the agent local, and why some of us pair a second machine.

Try it

GPR is free for projects, sessions, and the GitHub and Slack connections. You pay only for more workspaces or more tasks running at once. Get the app on Google Play, run the installer above, and send Claude something small you've been putting off.

Keep reading

New here? The launch post, Your AI coding agent is stuck in a terminal you have to babysit. So we built GetPullRequest would give a glimpse of what we are up against. Its the why we ditched cloud AI agents.

AI can run the software factory. It can't turn the lights off yet

Hari N — Sun, 04 Oct 2026 08:23:00 +0000

In 2018 Elon Musk admitted that excessive automation on the Model 3 line had been a mistake, and added: "Humans are underrated." Software is now having the same argument.

In January Dan Shapiro wrote up five levels of AI coding. Level 5 is the dark software factory , "a place where humans are neither needed nor welcome." A couple of weeks later StrongDM described how their AI team works, and Simon Willison wrote it up. Their rules:

Code must not be written by humans. Code must not be reviewed by humans. If you haven't spent at least $1,000 on tokens today per human engineer, your software factory has room for improvement.

We build GetPullRequest with coding agents, every day, and have since May (the launch post has the backstory). Most weeks it does feel like a software factory. It has never been dark, and below are a couple of the reasons why, straight out of our commit history.

TL;DR: An AI software factory, where agents do most of the work from ticket to pull request, is real, and we run one. The dark version, where no human writes or reviews anything, breaks on something manufacturing never had to solve: every unit of software is a new design, and working out whether it's right is the hard part. Automate the line, keep people at the few stations where judgment happens, and let them get there without sitting at a desk.

Manufacturing repeats a design. Software makes a new one every time

Lights-out manufacturing is real. FANUC has a plant where robots build robots and can run for long stretches with nobody on the floor, and there are a lot of videos of Chinese "dark factories" going around.

It works because the part was designed once and gets made a million times. The spec is a drawing with tolerances. Did the bracket come out at 40.00 mm, plus or minus 0.05? A gauge tells you, every time, for almost nothing. The design work happened months earlier, in another building, with the lights on.

Software doesn't have the million-copies part. git clone is the entire production line. Every ticket is a new design, so a "dark software factory" really means automating design and the checking of design. That's the part real factories never automated.

What broke when nobody was looking

Here's what that looks like in practice. Every one of these comes straight from our own commit history.

The agent said "done". There was nothing in it.

When an agent finished a task without changing any code, GitHub refused to open a PR, because there was nothing to compare. We'd decided early on that this wasn't really an error, since the task had run and nothing had crashed. So GPR quietly skipped the PR step and moved the task to Done anyway.

What we saw on the board was a green task, a "PR opened" event in its timeline, and no PR. Every automated signal agreed it was a success. The agent had exited cleanly and written a confident summary, and no test failed because there was nothing new to test. An agent that never touched the repo looked exactly like one that had finished the job, unless a person went looking for the diff. The checker had the same blind spot as the worker. In August we flipped it: no commits now means the task failed.

One wrong character hid two bugs.

Tasks were timing out after 90 seconds and we couldn't see why. The log line meant to explain it came out as an empty template, because it used %q, a Go formatting code, inside Python. Python choked on it, the logger swallowed the error, and the one number we needed (had the agent replied at all?) never got printed.

Worse, a test had been failing on exactly this for a while, and we'd been writing it off as an environment problem. Once the log was fixed, the next bug showed up behind it: under the right timing the daemon could start two agents for one session , and the extra one became a ~300 MB process nothing would ever clean up. Production showed one session spawned twice within 2.2 seconds. Even after both fixes, the original timeout still wasn't explained. We'd only made the next one visible.

A pipeline that just wants CI green, with nobody reading logs, would have called that test flaky and rerun it. That's what we did too, until someone read the log.

StrongDM's answer to this kind of problem is smart. They keep scenarios , end-to-end user stories, outside the codebase like a holdout set so the agents can't game them, and they score "satisfaction" probabilistically rather than pass/fail. Right instinct. But someone writes the scenarios, and someone decides what satisfied means. That's review, moved upstream.

The digital twin doesn't know the world changed

StrongDM's other big idea is the Digital Twin Universe : behavioural clones of Okta, Jira, Slack and Google Docs, so agents can test at volumes the real APIs would rate-limit. Hitting real Slack in a loop is miserable, so we get it. Two of our worst integration bugs this year would have gone straight through one, though.

Jira changed under us.

In September Atlassian removed an old search endpoint and our Jira calls started coming back 410 Gone. A Jira twin built in August would have kept happily returning results. The fix was itself a Jira ticket, PET2-4, which GPR picked up and turned into PR #500, tests passing first try. So the factory part was fine. It needed someone to notice the 410 and write the ticket.

Slack ate our screenshots.

Slack delivers every @gpr mention twice , and the attached files are only on one of the copies. We were reading the other one, so the screenshots people attached to bug reports silently disappeared (more in the Slack post). Nobody puts that in a clone, because nobody knows about it until a real person's screenshot goes missing.

Our real environment wouldn't fit in a sandbox.

Before GPR we tried hosted sandboxes, with Daytona. Getting our backend, Flutter app, database and Go daemon to come up together in there was a project of its own, and we gave up (more in the pillar post). Then there's Windows, where connections went half-open without the daemon noticing and our pairing QR code printed as an empty box in Windows Terminal. No twin was going to tell us any of that.

As for the $1,000 a day: Simon called it "more of a business model exercise", and it isn't the real problem anyway. Spend that much with no reliable way to tell whether the output is right and you've bought a faster way to ship things nobody checked.

	Manufacturing dark factory	"Dark" software factory	What we run
Each unit is	A copy of one design	A new design	A new design
"Is it right?"	A gauge, cheap and certain	Agents grading agents	Agents first, then a person merges
When the world changes	Rarely	The twin doesn't know	Whoever's on the board notices

What our software factory looks like

It is a factory. Tickets come in from GitHub issues with a label, from Jira, from a Slack mention. A daemon on one of our machines picks each up, makes a git worktree, starts whichever agent suits it, runs plan, implement, verify, and opens a PR. 370 commits in our repo carry Co-authored-by: GPR, and the branch list is mostly gpr/task-tsk_…. The conversation minimap in the task screen was PR #318, which GPR opened against its own repo.

The lights are on at three stations. Somebody writes the task, which is where the design happens; a vague ticket gets you a confident, wrong PR. Somebody answers the agent when it stops to ask, which happens more than you'd think and is honestly the most useful thing it does. And somebody reads the diff and merges.

Most of what a person does at those stations is small. Answer "should I keep the old endpoint as a fallback?", approve a command, read a 40-line diff, merge. None of it needs a desk. That's basically the product: agents run on your machine, your phone buzzes when one needs you, and you review and merge from there. If you only ever drive one Claude session, Claude Code Remote Control does the phone part fine.

It's not frictionless. PR #502, worktree badges leaking into unrelated chat sessions, took four agent rounds. PR #490, inline comment gestures not registering on diffs, took five. Somebody looked at every round. That's a normal week.

Where we might be wrong

Models will get better at checking their own work, and holdout scenarios are a real step. For a CRUD service with great coverage and no third-party APIs, a mostly dark pipeline could probably work today. And if review really goes away, the phone half of our product matters a lot less. Worth saying, since we're the ones selling it.

Our bet is that the stations move and don't disappear. Fewer people typing, more people deciding what gets built and saying yes or no to what comes back.

Keep reading

Your AI coding agent is stuck in a terminal you have to babysit. So we built GetPullRequest
We ditched cloud AI coding agents. Our laptops were faster, and already paid for
We merge pull requests from our phones. It's less reckless than it sounds
A Jira AI agent fixed our Jira integration
Devin AI alternatives: why pay for another AI engineer?
Agent Client Protocol (ACP) is the most important AI coding standard nobody's talking about

Try the lit version

GPR is free for projects, sessions, and the GitHub and Slack connections; you pay only for more workspaces or more tasks running at once. Get the app on Google Play (iOS app coming soon), then on a Mac, Linux or Windows machine with one coding agent installed:

curl -fsSL https://getpullrequest.com/install | bash
cd ~/code/your-repo
gpr setup # scan the QR code with the app

Give it something small and boring first, then go do something else until your phone buzzes.

Your AI coding agent is stuck in a terminal you have to babysit. So we built GetPullRequest

Hari N — Fri, 02 Oct 2026 17:03:00 +0000

The agents got good. Claude Code, Codex, Cursor and the rest can take a well-written ticket and produce a change you'd actually merge. What didn't change is everything around them. The agent lives in a terminal on your laptop. It stops to ask a question while you're in a meeting, and the question sits there for two hours. When it finishes, the PR waits until you're back at a desk.

We felt this every day, because we were building a product with four of these agents at once. GetPullRequest (GPR) is what we built to fix it, and we've built GPR with GPR since May. This post explains the gap we saw, where GPR fits, what it's bad at, and where we think this is going.

TL;DR: GPR runs the coding agent you already pay for, on the machine that already builds your project. Tasks come in from GitHub, GitLab, Jira or Slack, and a pull request comes back to your phone. It's free to start.

Two answers, both from the vendors

The industry has offered two answers to "my agent is stuck at my desk".

The first is to move the agent into the vendor's cloud. Devin, GitHub's Copilot coding agent, Codex cloud and Cursor's Cloud Agents all work this way. You hand over a ticket, a VM somewhere clones your repo, and a PR comes back. For a project that builds from a clean checkout in two minutes, that's great.

Ours doesn't. Our repo has a FastAPI backend, a Flutter app, a database and a Go daemon that all need to come up together. We tried hosted sandboxes first, with Daytona, and gave up for three reasons. Wiring all four pieces together inside a sandbox, and keeping them working as the code changed, was a project in itself. It cost money a small startup didn't want to spend while our own laptops sat idle half the day. And testing was slow : every check meant a checkout and a full build to recreate an environment that already existed, fully built, on the laptop in front of us. Hosted agents also usually mean another subscription, billed per task or at API prices, on top of the agent plans we already paid for.

The second answer is a remote for your own machine. Claude Code has Remote Control, and Codex now connects to the ChatGPT app. These keep the agent local, which we think is right. But each one is a remote for one vendor's agent, and it's built around a session you started yourself. Our work doesn't arrive that way. It arrives as a GitHub issue, a Jira ticket from someone in product, or a screenshot in Slack. It goes to whichever agent suits it, and it should end as a pull request, not a chat log.

"Work doesn't arrive as a chat session. It arrives as a GitHub issue, a Jira ticket from someone in product, or a screenshot in Slack."

The gap

Put those side by side and one combination is missing. Nothing ran the agent you already pay for, on the machine that already builds your project, fed by the tools where work actually gets asked for, and handed back a PR you could review from anywhere.

	Vendor cloud agents	Vendor remotes	GetPullRequest
Where the agent runs	Their VM	Your machine	Your machine
Which agent	Theirs	Theirs	Any ACP agent you already pay for
Where tasks come from	Their app, sometimes GitHub	A session you started	GitHub, GitLab, Jira, Slack, the app
What comes back	A PR	A chat	A PR you merge from your phone

That's GetPullRequest. A small daemon runs on your machine. It takes tasks from the board in our phone app, from GitHub issues labelled gpr:agent, from Jira, or from an @gpr mention in Slack. For each task it creates a git worktree, starts your agent, and runs plan, implement and verify. Then it opens a PR. Your phone shows the session live, buzzes when the agent has a question, and lets you read the diff and merge.

Two decisions that shaped everything

We don't ship our own agent. Developers already pay for one or two. Asking them to buy another before they can try GPR is friction, and it's paying twice for the same thing. We didn't know how to support every agent without writing an integration per agent. Then we watched Ben Brandt from Zed and people from JetBrains explain the Agent Client Protocol. ACP solves the editors-times-agents problem for IDEs, and we realised a phone could be just another client. GPR now runs Cursor, Claude Code, Codex, Kiro, OpenCode, Qwen, Cline and Copilot through it. The ACP post goes deeper.

The cloud only enriches. Everything core works with nothing connected: the board, the queue, the agent run, the diff and the merge check. The diff and merge check come from git on your machine, because that's where the agent's work actually is, including changes GitHub has never seen. GitHub, GitLab, Jira and Slack plug in as adapters behind ports, and they only add to what's there. When Atlassian removed an old search endpoint in September and our Jira calls started returning 410 Gone, agents kept working. Only new tickets stopped syncing. The fix was ticket PET2-4, which GPR picked up from Jira and turned into PR #500, with tests passing on the first attempt.

Built with itself

By the time of writing, the GPR code had about 450 commits. 370 of them are co-authored by GPR. Our branch list is full of gpr/task-tsk_… names, which is what GPR calls the branches it creates. The conversation minimap in the task screen was PR #318, opened by GPR against its own repo. When worktree badges started leaking into unrelated chat sessions, the fix was PR #502, and its squash shows four agent iterations before the change was right.

Building it this way also meant we hit every rough edge first. In August one machine had 52 cursor-agent processes running after six and a half minutes, about 300 MB each, because they raced on a config file and ignored SIGTERM. Windows sockets went half-open and the daemon never noticed. Agents finished turns with no commits and GPR marked them done. Each of those is fixed now, and most of the fixes were written by agents through GPR. The stories are spread across the posts in this series.

What it's not good at

A machine has to be on. If your laptop sleeps, its tasks wait until it wakes, so people who want agents working overnight end up pairing a desktop. The Android app is live, and iOS isn't in the App Store yet. The phone is good for answering a question, approving a command, reading a small diff and merging. It's not good for reviewing a big architectural change, and we don't pretend otherwise. If you only use one agent and want to poke at one session, Claude Code Remote Control or the ChatGPT app is simpler. But still its not smooth with other tools that you are operating with. You have to deal with lot of rough edges which GPR is designed to handle.

Where this is going

Our bet is that most engineering work will look like what our team already does. Engineers spend less time typing code and more time deciding what should be built, writing tasks an agent can finish, and reviewing what comes back. The code still gets built and tested where it always was, on machines the team controls. The agents become interchangeable, and you pick one per task the way you'd pick a library. Work arrives from wherever people already talk about it.

The useful product isn't another agent. It's the layer between where work is asked for and where it's done.

In that world, the useful product isn't another agent. It's the layer between where work is asked for and where it's done, and the thing in your pocket that lets you keep up with it. That's what we're building GetPullRequest into.

What's next on this blog

Over the next two weeks we'll publish the rest of this series. Each post takes one tool people already use and is honest about where it beats us:

Claude Code Remote Control is great. It's also not enough
Agent Client Protocol (ACP) is the most important AI coding standard nobody's talking about
Cursor background agents charge you twice for compute you already own
Codex CLI remote control: stop babysitting the terminal and let it ship PRs while you're out
Slack AI agents should open pull requests, not summarize threads
A Jira AI agent fixed our Jira integration
Devin AI alternatives: why pay for another AI engineer?

Try it

GPR is free for projects, sessions, and the GitHub and Slack connections. You pay only for more workspaces or more tasks running at once. Get the app on Google Play, (iOS app coming soon) then on a Mac, Linux or Windows machine with one coding agent installed:

curl -fsSL https://getpullrequest.com/install | bash
cd ~/code/your-repo
gpr setup # scan the QR code with the app
gpr discover # lists which agents are ready

Start with a small, boring task, something you'd normally put off, and see what's waiting for you when you get back.

DEV Community: GetPullRequest

Ship code from your phone with the AI coding agents you already pay for

Claude Code remote control, Codex, Cursor background agents: why not just use those?

How a task actually runs

Why AI coding agents should run on your machine: faster, and already paid for

Everything works with nothing connected

Some weird issues we hit while building it

Agent Client Protocol: why we never built our own coding agent

What a phone is actually good for (the Claude Code mobile app question)

Still rough

Trying it

Related posts

Agent Client Protocol (ACP) is the most important AI coding standard nobody's talking about

The problem the Agent Client Protocol solves

How it works

Agent Client Protocol vs MCP

How we found it

What GPR does with ACP

Agent Client Protocol with Claude Code

What the protocol doesn't fix

Your keys stay where they are

Try it

Keep reading

Claude Code Remote Control is great. It's also not enough

Setting up Claude Code remote control

Claude Code remote control not working?

Where it stopped being enough for us

Running Claude Code through GPR

Giving Claude a task

Rough edges

Try it

Keep reading

AI can run the software factory. It can't turn the lights off yet

Manufacturing repeats a design. Software makes a new one every time

What broke when nobody was looking

The digital twin doesn't know the world changed

What our software factory looks like

Where we might be wrong

Keep reading

Try the lit version

Your AI coding agent is stuck in a terminal you have to babysit. So we built GetPullRequest

Two answers, both from the vendors

The gap

Two decisions that shaped everything

Built with itself

What it's not good at

Where this is going

What's next on this blog

Try it