Kay

Posted on Nov 15 Originally published at latchkey.dev

Cursor Agent CI and Copilot coding agents, wired into Actions

#devops #ai #cicd #githubactions

Cursor Agent CI and GitHub Copilot's coding agent look like the same problem and are not: one is a command you run inside a workflow you already own, and the other works in an environment of its own, a GitHub-hosted cloud sandbox by default or an Actions job you choose, and sends its pull requests into your CI. Getting either wrong produces the same symptom, a pull request that sits there with no checks on it.

The two wiring problems this page covers, and where each agent does its work. Behavior read from both vendors' docs on 2026-11-12.

There are two directions and they need different work. In the first the agent runs inside CI: a step in your workflow invokes it, with an API key and whatever permissions the job carries. In the second the agent runs somewhere else and its pull requests arrive at your CI, which is a question about triggers, approvals and trust rather than about installing anything.

Cursor is mostly the first. Copilot's coding agent, which GitHub now calls Copilot cloud agent, is mostly the second; its own work happens in a cloud sandbox by default, or in an Actions job when you choose that environment. Each direction gets its own sections, then the part they share.

Direction one: the agent as a step

The Cursor CLI is installed with a one-line script and then invoked in print mode, which its documentation describes as the non-interactive mode for scripts, CI pipelines or automation. Two lines of setup matter: the installer writes into $HOME/.cursor/bin, so that path has to be added to $GITHUB_PATH for later steps to find it, and the API key arrives as CURSOR_API_KEY from a repository secret.

What you do with it is the interesting choice. Running an agent to fix a failing build inside the same workflow that detected the failure is a tight loop and a poor idea on any repository accepting outside contributions, because the log it reads contains text a stranger wrote. Running it on a schedule against your own default branch, opening a pull request a human reviews, is the same capability with the blast radius removed.

```.github/workflows/agent.yml, install and invocation quoted from the Cursor CLI GitHub Actions documentation

name: Install Cursor CLI
run: |
curl https://cursor.com/install -fsS | bash
echo "$HOME/.cursor/bin" >> $GITHUB_PATH
- name: Run Cursor Agent env: CURSOR_API_KEY: ${{ secrets.CURSOR_API_KEY }} run: | agent -p "Your prompt here" --model gpt-5 ```

Cursor documents a Windows install line too, irm 'https://cursor.com/install?win32=true' | iex. Both install from a URL at job time, which is a supply-chain dependency on every run; pinning matters here the way it matters for any curl | bash in CI.

What that step is allowed to touch

A step like the one above runs with the job's permissions and can read every secret the job can read, which is the whole security question in one sentence. Give the job the narrowest permissions block that lets it do its work, and keep the agent out of workflows triggered by events an outsider controls.

The rule that survives every variation of this: the log is data, never instructions. On a repository that takes pull requests from forks, a test name, an assertion message or a dependency's output was written by whoever opened the pull request, and you are about to hand it to something with write access to your tree. The trust boundaries for agent-authored changes are worked through in testing AI-generated pull requests in CI.

Direction two: Copilot brings its own environment

Copilot runs a session in one of two hosted environments. Cloud is a sandbox GitHub hosts and, where a client lets you choose, the default; Actions is a job on a GitHub-hosted runner or one you configure, prepared by a workflow at .github/workflows/copilot-setup-steps.yml. The choice is made when the session starts and cannot be changed afterwards, and setup steps, larger and self-hosted runners and Windows apply only on the Actions path. The file's rules, its runners and its secrets are on copilot-setup-steps.yml.

The gate that holds every agent pull request

This is the behavior that sends people to the issue tracker, and it is deliberate. GitHub documents that by default, Actions workflows will not run automatically when Copilot pushes changes to a pull request, because workflows can be privileged and have access to sensitive secrets. Somebody with write access clicks Approve and run workflows in the merge box, and only then does CI start.

The listed mitigations around it are worth knowing because they shape what an agent workflow can look like at all. Only users with write access can trigger the agent. It can push to exactly one branch. Its draft pull requests must be reviewed and merged by a human, and it can neither mark them ready for review nor approve or merge them. And when it opens a pull request under its own app identity, one more approval is required before merging on a repository that already requires at least one.

Runners: whose, and how big

For a Cursor step the answer is the job's own runs-on, billed like any other job. For Copilot it depends on the environment: a session in a cloud sandbox runs on no runner of yours, and a session on Actions runs where the setup steps file and any organization default send it. Either way, the pull request it opens runs your own workflows on your own runners once someone approves them.

Question	Cursor CLI in your workflow	Copilot cloud agent
Where does the agent run?	A step in a job you wrote	A cloud sandbox by default, or an Actions job you choose
What configures it?	The workflow file, like any step	On Actions, `.github/workflows/copilot-setup-steps.yml`
What authenticates it?	`CURSOR_API_KEY` from a repository secret	Its own token, issued by GitHub
Who picks the runner?	You, in `runs-on`	On Actions, the setup steps, unless the org locks it
Do checks run on its pull request?	Whatever your triggers say	Not until someone clicks Approve and run workflows
Can it merge its own work?	Only if you give it a token that can	No; a human must review and merge

What to actually run on an agent pull request

The same suite you run on a human one, plus two things that catch the specific mistakes models make. A lockfile check, because a dependency added without regenerating the lockfile is the most common agent-authored breakage and it fails much later than it should. And a diff-size or path guard, because the second most common is a refactor that quietly edits twenty files nobody asked about.

Everything else is ordinary. The value of a fast pipeline goes up sharply here, because an agent loop that waits twelve minutes for feedback is an agent loop that is mostly waiting, and the cost of a slow one is now paid per iteration rather than per human. That is the practical argument for the rest of the faster GitHub Actions material rather than a separate discipline.

What no run backs here

Nothing on this page was reproduced on a runner, and the reason is that both mechanisms need an account we would have to buy and an identity we would have to be. Copilot's approval gate lives in a merge box on a pull request opened by an app, and the Cursor step needs a paid API key; capturing either would produce a screenshot of our account rather than evidence about the product.

So every behavior above is quoted from the vendor documentation that defines it, first read on 2026-09-21 and checked again on 2026-11-12, when GitHub's pages had renamed the agent and made a cloud sandbox the default environment. The load-bearing string, the approval button, is quoted rather than paraphrased because it is the one a paraphrase would get subtly wrong. What a runner should hand an agent when a job does fail is a separate question with its own committed run, in CI failure reports your agent can read.

FAQ

How do I run the Cursor agent inside GitHub Actions?

Install the CLI in a step with curl https://cursor.com/install -fsS | bash, append $HOME/.cursor/bin to $GITHUB_PATH so later steps find it, then invoke it in print mode: agent -p "your prompt" --model <model>. Authentication is a CURSOR_API_KEY environment variable taken from a repository secret. Cursor documents print mode as the non-interactive mode for scripts, CI pipelines and automation.

Why do no checks run on a pull request opened by Copilot?

Because GitHub holds them by default. Its documentation states that Actions workflows will not run automatically when Copilot pushes changes to a pull request, since workflows can be privileged and have access to sensitive secrets. A user with write access clicks Approve and run workflows in the merge box to release them, and there is an optional setting to let them run without that intervention.

How do I let workflows run automatically on Copilot's pull requests?

A repository administrator can switch off Require approval for workflow runs under Settings, Copilot, Cloud agent, in the Policies section. GitHub warns that this may let unreviewed code written by Copilot gain write access to the repository or reach your Actions secrets, so weigh it against what your workflows hold. The setting, and every rule for the setup steps file, are covered on copilot-setup-steps.yml and in GitHub's agent settings page.

Why does Copilot push changes that fail my CI checks?

Copilot can run tests and linters in its own environment before it pushes, and GitHub's troubleshooting page says it is most likely to do so when told clearly how, in a .github/copilot-instructions.md file. Name the exact commands your CI runs there. If the session runs on Actions, make sure the setup steps install what those commands need, or the agent has nothing to run them with.

DEV Community