Trae is a loop. Its Builder agent reads your repository, edits files, runs commands in the terminal, and reads the output to decide what to do next. So why aren’t your API tests in that loop? They sit in Apidog behind a GUI and run when someone remembers to click. Your agent never touches them.
The fix is one config block. 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 Trae knows it exists, the Builder 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, authentication, and the first run, with the agent doing the typing. This article assumes apidog --version prints a number and your Apidog account is authenticated.
Which Trae this is about
Trae is ByteDance’s AI IDE, built on VS Code, with an agent mode called Builder that edits files and runs terminal commands on its own. You can read the product details on Trae’s official site. This article is about the desktop IDE, not the standalone trae-agent research project on GitHub. If you open Trae, see a chat panel next to your editor, and can switch the agent to Builder, you are in the right place.
The distinction matters because Trae has its own way of learning project rules, and that mechanism turns a one-off “run my tests” into something the Builder reaches for on its own. That mechanism is a project rules file. If you want the tool-agnostic version of this workflow first, the complete Apidog CLI guide covers the CLI on its own.
Step 1: Add the project rules file
Trae reads rules files before the Builder starts working. The project-level file lives at .trae/rules/project_rules.md at your repository root, per Trae’s rules documentation. The Agent loads these rules during initialization and references them while it generates and edits code. There is also a user-level user_rules.md that applies across all your projects; for this workflow, one project file at the repo root is enough.
Create .trae/rules/project_rules.md and add a short block that names the CLI, the exact scenario command, and the rules that keep the Builder honest:
## API testing with the Apidog CLI
When you change code that touches an API endpoint, verify it by running the
Apidog test scenario, not just the unit tests.
Command:
apidog run -t <scenario_id> -e <env_id> -r cli
Rules:
- `apidog run` exits 0 when every assertion passes and non-zero on any failure.
Treat a non-zero exit code as a failing test, even if the summary looks fine.
- This machine is already authenticated via `apidog login`. Never add an
--access-token flag and never put a token in this file.
- If a flag is unknown, run `apidog run --help` and use the exact flag from there.
This is why you write the CLI into project_rules.md instead of mentioning it in chat. A scenario ID typed into the chat panel is gone when the session ends. One in .trae/rules/project_rules.md is there for every teammate and every Builder run from now on. Trae also reads .trae/rules/ folders in subdirectories, so a monorepo can keep per-service rules next to each service.
Step 2: Get the command from Apidog
You do not have to guess the command. Open the test scenario in Apidog, go to its CI/CD tab, and copy the generated apidog run line. It already has the real scenario ID after -t and the environment ID after -e, so you are pasting a command Apidog knows is valid rather than inventing IDs by hand.
Drop those exact IDs into the block in .trae/rules/project_rules.md, replacing the <scenario_id> and <env_id> placeholders. For the full set of flags and what each one does, see the apidog run command reference.
Step 3: Have the Builder run the test
With the block in place, switch Trae’s agent to Builder and start it in your repo. The Builder loads project_rules.md as it initializes, so it already knows the CLI is there. Make a change that touches your API, or just ask it to run the check:
Run the Apidog test scenario and tell me the exit code.
The Builder issues the apidog run command from your rules file. Trae’s approval model matters here: when the agent wants to run a shell command, it recommends the command and shows a Run button, and the command executes in Trae’s terminal only after you click it. Once it runs, the Builder automatically reads and analyzes the output. So you approve the apidog run once, and the agent takes the result from there.
The -r cli reporter prints a step-by-step result and a summary right in the terminal, where the Builder reads each request and assertion as it happens. You want to see the run executing and the Builder reporting back both the summary and the exit code.
Step 4: Read the report inside Trae
When a run goes red, the report has the answer. With -r cli, the Builder gets a readable breakdown in Trae’s 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 the Builder to find the fix.
For a report you can open in a browser or hand to a teammate, add the HTML reporter:
apidog run -t <scenario_id> -e <env_id> -r cli,html
The html reporter writes a self-contained file to ./apidog-reports. Keep cli in the list so the Builder still gets the inline output it reads to decide its next step. For every reporter, including the JSON and JUnit formats CI dashboards parse, see the guide to Apidog CLI test reports.
Trae testing inside its own loop
The point is what happens when you stop asking and the Builder runs the scenario on its own because project_rules.md told it to.
Picture the Builder 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 the Builder already runs your unit tests through. You wrote one instruction and the Builder folded the command into how it already works.
This is the delegate-then-verify model that makes any agent workflow safe. The Builder 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 Trae is actually running the CLI
Agents report success they did not earn, and the Builder is no exception. Three checks, in order of how often they catch problems.
First, confirm the command ran at all. Trae shows the commands the Builder executed and their output in the terminal. Look for the literal apidog run line and a result under it. If the Builder 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:
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 the Builder, or a pipeline, treat the run as a clean gate. When the Builder’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,” the Builder may have invented or misremembered an ID. Re-check the -t and -e values against project_rules.md and the command Apidog generated in the CI/CD tab. The IDs in your rules file are the truth.
Optional: connect the Apidog MCP server
Running apidog run from project_rules.md covers most of what you need. Connecting an MCP server goes one step further. Trae agents act as MCP clients, so the Builder can call tools that an MCP server exposes.
To add one, open Trae’s settings, go to the MCP tab, and either pick a server from the marketplace or choose Add Manually and paste a JSON block with the server’s command, args, and env, per Trae’s guide to adding MCP servers. The Apidog MCP server exposes your API specifications over MCP, so the Builder 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.
When Trae gets it wrong
A few failures show up often during setup.
It ignores the rules file. If the Builder runs a generic command or none at all, the file may not be loading. Confirm it is at .trae/rules/project_rules.md at your repository root and that the folder is named rules, not rule. Restarting the session forces a fresh read of the rules.
It passes an access token anyway. If the Builder 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 project_rules.md. For how the CLI handles credentials in interactive use and in CI, see Apidog CLI authentication.
It invents a flag. An “unknown option” error means the Builder 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 your project_rules.md 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 .trae/rules/project_rules.md, and the Builder 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 the Builder 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 the Builder 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 .trae/rules/project_rules.md, and watch the Builder pick it up on the next change. When you are ready to run the same scenario without an agent present, Apidog CLI in GitHub Actions covers the secrets, reporters, and exit-code gating for CI.
