GitHub Copilot’s agent mode is a loop: it edits files, runs terminal commands, reads the output, and decides what to do next. So why aren’t your API tests in that loop? They sit in Apidog behind a GUI, run when someone remembers to click. Copilot never touches them.
The fix is one config file. The Apidog CLI is an npm package, apidog-cli, that runs the test scenarios you built in Apidog straight from a terminal. Once the CLI is installed and Copilot knows it exists, agent mode runs an Apidog scenario the same way it runs your unit tests: fire the command, read the exit code, fix the code if it is red.
If you have not installed the CLI yet, do that first. How to install the Apidog CLI with an AI coding agent walks through the npm install, the login, and the first run, with an agent doing the typing. This article assumes apidog --version prints a number and your Apidog account is authenticated.
Which Copilot this is about
Copilot is several products, and the name overlaps in confusing ways. This article is about the surfaces that can run shell commands.
The main one is agent mode in VS Code. You open the Copilot Chat view, switch the mode dropdown to Agent, and it can edit multiple files, run terminal commands, and iterate until the task is done. When it wants to run a command, it shows you the command and asks for confirmation before executing. That confirmation step is exactly where apidog run fits.
Two related surfaces are worth naming so you know which one you are in. The Copilot coding agent runs asynchronously in GitHub Actions after you assign it an issue; it produces a pull request rather than working in your editor. The Copilot CLI is a separate terminal client. Both can run commands, but this article targets agent mode in VS Code, because that is where you sit while you code and where the edit-test-fix loop is tightest. The setup below also works for the coding agent, which reads the same instructions file. For a broader tour of what changed when Copilot became agentic, see GitHub Copilot’s new coding agent.
The distinction matters because Copilot has its own way of learning project rules, and that mechanism turns a one-off “run my tests” into something Copilot reaches for on its own. That mechanism is a custom instructions file.
Step 1: Add the Apidog rules to Copilot’s instructions file
Copilot reads repository custom instructions from a single file: .github/copilot-instructions.md at the root of your repo. Agent mode, Copilot Chat, code review, and the coding agent all load it automatically, per the GitHub docs on repository custom instructions. Think of it as CLAUDE.md for Claude Code or AGENTS.md for Codex: a plain Markdown file of project instructions Copilot pulls into context before it starts working.
Create the file and add a short Apidog block:
## API testing with the Apidog CLI
When you change an API endpoint, verify it with the Apidog CLI before
declaring the task done. Run:
apidog run -t 812345 -e 671234 -r cli
- `apidog run` exits 0 when every assertion passes, non-zero on any failure.
Treat a non-zero exit as a failing test, even if the summary text looks fine.
- The machine is already authenticated via `apidog login`. Do NOT add an
`--access-token` flag and never put a token in this file.
- If you hit an "unknown option" error, run `apidog run --help` and use the
real flags. Do not guess.
Replace the -t and -e values with your real scenario and environment IDs from the next step.
Write it into the instructions file instead of mentioning it in chat because a scenario ID typed into chat is gone when the session ends. One in .github/copilot-instructions.md is there for every teammate, every agent-mode session, and every pull request the coding agent opens from now on. If you want the rule to apply only to certain files, GitHub also supports path-specific instructions in .github/instructions/NAME.instructions.md, but a single repo-wide file is enough here.
Step 2: Get the command from Apidog
You do not have to write the apidog run command by hand. Apidog generates it for you.
Open the test scenario in Apidog, go to its CI/CD tab, and copy the command. It comes out fully formed with the correct scenario ID (-t), environment ID (-e), and a reporter flag:
apidog run -t 812345 -e 671234 -r cli
Paste those exact IDs into the block in your .github/copilot-instructions.md. These IDs are the source of truth; when Copilot and your instructions file disagree, the CI/CD tab wins. For the full set of flags and reporters, see the apidog run command reference.
Step 3: Have agent mode run the test
Open the Copilot Chat view in VS Code and switch the mode dropdown to Agent. Because agent mode loads .github/copilot-instructions.md as it starts, it already knows the CLI is there. Make a change that touches your API, or ask it directly:
Run the Apidog API test scenario and tell me the result.
Copilot issues the apidog run command from your instructions file. Agent mode does not run terminal commands silently; it shows you the command and asks you to confirm before it executes, so you see exactly what is about to run. Approve it. The -r cli reporter then prints a step-by-step result and a summary right in the integrated terminal, where you watch each request and assertion as it happens.
You want to see two things: the run executing, and Copilot reporting back both the summary and the exit code. If you approve the command once, VS Code can remember your choice for that command in the workspace, so later apidog run calls execute without re-prompting. A read-only test scenario against staging is exactly the kind of safe, in-workspace command that is fine to allow.
Step 4: Read the report inside Copilot
When a run goes red, the report has the answer. With -r cli, Copilot gets a readable breakdown in the terminal: each request, each assertion, and which one failed with expected versus actual value. The failing assertion names the exact field or status code, which is usually enough for Copilot to find the fix on its next iteration.
For a report you can open in a browser or hand to a teammate, add the HTML reporter:
apidog run -t 812345 -e 671234 -r cli,html
The html reporter writes a self-contained file to ./apidog-reports. Keep cli in the list so Copilot still gets the inline output it reads to decide its next step. For every reporter format, including the JUnit output CI dashboards parse, see the complete Apidog CLI guide and how to read Apidog CLI test reports.
Copilot testing inside its own loop
The point is what happens when you stop asking and Copilot runs the scenario on its own because the instructions file told it to.
Picture agent mode editing a handler that builds a checkout response. Its loop changes. It edits the code, then, instead of declaring victory, runs your Apidog scenario against staging, reads the exit code, and acts on it. Green, it moves on. Red, it opens the report, reads which assertion failed (the status code, the missing field, the wrong value), tries a fix, and re-runs. The API test becomes part of the same edit-test-fix loop Copilot already runs your unit tests through. You wrote one instruction and Copilot folded the command into how it already works.
This is the delegate-then-verify model that makes any agent workflow safe. Copilot runs the command and reads the result; you keep authoring scenarios visually in Apidog and spot-check that the agent reads exit codes honestly. For the broader pattern, see how to use AI agents for API testing and the Apidog AI test harness.
Verify Copilot is actually running the CLI
Agents report success they did not earn, and Copilot is no exception. Three checks, in order of how often they catch problems.
First, confirm the command ran at all. Agent mode shows the commands it executed and their output inline in the terminal. Look for the literal apidog run ... line and a result under it. If Copilot says it ran the tests but you do not see the command, it summarized something it never did. Ask it to run again and show the raw output.
Second, confirm the exit code, the one that matters:
What was the exit code of that apidog run command?
apidog run exits 0 when every assertion passes and non-zero when anything fails. That single behavior lets Copilot, or a pipeline, treat the run as a clean gate. When Copilot’s prose says “tests passed” but the exit code is non-zero, the exit code is right.
Third, confirm it used the real scenario. If a run fails with “scenario not found,” Copilot may have invented or misremembered an ID. Re-check the -t and -e values against your instructions file and the command Apidog generated in the CI/CD tab. The IDs from Apidog are the truth.
Optional: connect the Apidog MCP server
Running apidog run from your instructions file covers most of what you need. To go one step further, connect the Apidog MCP server.
Agent mode in VS Code reads MCP servers from a workspace .vscode/mcp.json file at your repo root, per the GitHub docs on extending Copilot with MCP. The Apidog MCP server exposes your API specifications over MCP, so Copilot can read your schema while it writes code, not just after the fact. The division of labor is clean: the CLI runs the tests, and MCP feeds the agent the spec.
If you run the Copilot coding agent in GitHub Actions instead, its MCP config lives in a different place. You add it as JSON under the repository’s Settings, in the Copilot section under Cloud agent, with any secrets stored as Actions secrets prefixed COPILOT_MCP_. The .vscode/mcp.json file is for agent mode in your editor.
When Copilot gets it wrong
A few failures show up often during setup.
It ignores the instructions file. If Copilot runs a generic command or none at all, the file may not be loading. Confirm it is named exactly .github/copilot-instructions.md, sits in the .github directory at your repo root, and that custom instructions are enabled in your VS Code settings. A wrong path means Copilot never reads it.
It passes an access token anyway. If Copilot tries to add --access-token, it is guessing from public examples. The block already tells it not to, since the machine is authenticated via apidog login. Reinforce the line, and never put a real token in the instructions file. For the auth model, see Apidog CLI authentication.
It invents a flag. An “unknown option” error means Copilot guessed a flag your version does not have. Tell it to run apidog run --help and copy the exact flag from there, which is always correct for your installed version.
It reports a pass on a failed run. The costliest one, and the reason the exit-code rule is in both your instructions file and your verification step. When the summary and the exit code disagree, the exit code wins.
From a daily agent to a tested loop
That is the setup. Install apidog-cli once following the install guide, add a short Apidog block to your repo’s .github/copilot-instructions.md, and Copilot knows how to run your API tests and read the result inside the same loop it already uses to edit code. A broken endpoint gets caught while Copilot is still working on the change, not after it ships.
A test behind a GUI runs when a human clicks; a one-line command runs whenever Copilot decides to. You keep building scenarios visually in Apidog, and your agent runs them where you are not watching. Download Apidog, build one scenario, drop its apidog run command into .github/copilot-instructions.md, and watch Copilot pick it up on the next change. When you are ready to run the same command in a pipeline without Copilot present, Apidog CLI in GitHub Actions covers the secrets, reporters, and exit-code gating.
