Refinar

team workflow · 5 min read

What a Background Coding Agent Does Between Your Request and the Pull Request (2026)

A background coding agent takes a ticket, works in a copy of your repo you never see, and returns a pull request. What happens in between, and what none of them show you.

Updated 2026-09-11

A request entering a sealed box labelled as a copy of the repository, and a pull request leaving it, with the work inside the box hidden from the reviewer

You assign an issue to Copilot, or paste a task into Codex, and some minutes later a pull request appears with your name near it. The demos make that gap look like magic. It isn't. Every one of these agents does roughly the same six things in the same order, and the vendors document most of it.

This is that sequence, written for the person who'll be asked to review what comes out, rather than for the engineer wiring it up.

It never touches your repository directly

The first thing an agent does is make a copy somewhere you can't see. Copilot works in what GitHub calls an ephemeral environment powered by GitHub Actions. Codex creates a container and checks out your branch into it. Jules spins up a fresh virtual machine for every task. Cursor's cloud agents run in isolated VMs with a full development environment.

Your repository only ever receives a branch. Copilot's push credentials work solely on branches beginning with copilot/, and it cannot push to main at all. That's the reassuring half of the story, and it's worth holding onto when the diff arrives.

Reading comes before writing

Inside the copy, the agent installs dependencies and explores the code before changing anything. Jules and Codex both look for an AGENTS.md file at the root, which is your chance to say where things live and what not to touch. Jules goes one further and drafts a plan you can approve before a single file changes.

The middle is a loop you don't watch

Then it works. The Codex docs sum up the agent phase as running terminal commands in a loop. Edit, run, read the error, edit again, until the task looks done or the agent gives up. You can close the tab. Jules will email you when it finishes or gets stuck.

Two things about that loop matter to a reviewer. First, on Codex the agent's internet access is off by default during the loop, so it can only use what the setup script installed. Jules's VM has internet. Second, on most of these tools you can't steer mid-run, so the quality of the result is set by the ticket you wrote, not by anything you do after pressing go.

What it can check, and what it can't

Every one of them can run your tests and linters inside the copy, and most will say so in the pull request. Read that claim carefully. Jules's docs are explicit that long-running processes like dev servers aren't supported in setup scripts, so a passing run means the unit tests passed, not that the app booted and the page rendered.

Copilot adds a wrinkle. When it pushes to a pull request, your GitHub Actions workflows don't run until someone with write access clicks Approve and run workflows. The green ticks you're used to seeing on a PR aren't there yet when Copilot hands it over. They appear after a human has already looked.

The handoff comes with rules attached

The output is a pull request, and on Copilot the pull request has guardrails GitHub built around it. Exactly one PR per task. It arrives as a draft, and Copilot can't mark it ready, approve it or merge it. The person who assigned the task can't approve it either, so a repository that requires one review gets a review from somebody else. Comments from people without write access are never shown to the agent, which closes the door on a stranger steering it through a public issue.

Cursor works on a separate branch and pushes it for handoff. Jules opens the PR for you and waits.

The part nobody shows you

Here's what all four have in common at the end. The reviewer gets a diff. Nobody gets the running app. If the change was a pricing card, the person judging it reads JSX and imagines the card, or checks the branch out locally and runs it, which is a developer's job by definition.

That's the gap Refinar was built around. It runs the same sequence, a private copy booted in a sandbox and a draft pull request at the end. The difference is that the copy is your app actually running, and a live preview updates while the agent works. So the person who asked for the pricing card can look at the pricing card. Changes that reach into sign-in, payments or customer data are held for a developer to approve, and the sandbox can only read from connected services until somebody allows a write. We make it, so weigh that sentence accordingly.

Three things to check when the PR lands