OpenClaw is a loop: it reads your workspace, runs shell commands through its exec tool, 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. 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 OpenClaw knows it exists, your agent 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.
This guide covers the OpenClaw-specific part the generic install guide skips: where to put the Apidog rules so the agent keeps them, how OpenClaw’s exec tool actually runs apidog run, and how to read the result.
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. This article assumes apidog --version prints a number and your Apidog account is signed in.
Which OpenClaw this is about
OpenClaw is the open-source, local-first AI agent that runs on your own machine. It has a workspace, a set of skills, and an exec tool that runs real shell commands. It is not a code-completion plugin and not a hosted chatbot. If you have run openclaw locally and watched it edit files and execute commands, you are in the right place. For the wider setup, see OpenClaw development workflow automation and the guide to a secure OpenClaw installation before you hand it any commands.
The distinction matters because OpenClaw learns project rules from workspace files, and that mechanism turns a one-off “run my tests” into something OpenClaw reaches for on its own. That mechanism is AGENTS.md.
Step 1: Add the Apidog rules to AGENTS.md
OpenClaw reads workspace files as standing instructions and injects them into the agent’s context. The one you want is AGENTS.md, the procedural rulebook that tells the agent what to do and how. Think of it as CLAUDE.md for Claude Code; OpenClaw even ships a default template you copy into your workspace, and it treats a sibling CLAUDE.md symlink as the same file. The workspace defaults to ~/.openclaw/workspace, but you can point an agent at your project directory with agents.list[].workspace, and OpenClaw supports scoped AGENTS.md files per subdirectory (see OpenClaw’s AGENTS.md reference).
Add a short block to your AGENTS.md:
## API testing with Apidog
- To run API tests, use the Apidog CLI: `apidog run -t <scenario_id> -e <env_id> -r cli`.
- Exit code 0 means every assertion passed. Non-zero means something failed. Treat it as the pass/fail gate.
- The machine is already authenticated with `apidog login`. Never add an --access-token flag and never put a token in this file.
- If a flag looks unfamiliar, run `apidog run --help` instead of guessing.
This is why you write the CLI into AGENTS.md instead of mentioning it in chat. A scenario ID typed into a session is gone when the session ends. One in AGENTS.md is there for every teammate and every OpenClaw run from now on.
Step 2: Get the command from Apidog
You do not have to write the scenario ID by hand. Open the test scenario in Apidog, go to its CI/CD tab, and copy the generated command. It looks like this:
apidog run -t 1234567 -e 890123 -r cli
The -t is the test scenario, -e is the environment, and -r cli is the reporter. Paste the real IDs into the AGENTS.md block from Step 1 so OpenClaw always calls the right scenario against the right environment. The complete Apidog CLI guide and the apidog run command reference cover every flag if you want to tune it.
Step 3: Have the agent run the test
With the block in place, start OpenClaw against your project and make a change that touches your API, or just ask it to run the check. Because AGENTS.md is already in context, the agent knows the CLI exists and issues the apidog run command through its exec tool.
The exec tool runs shell commands in the workspace, and OpenClaw gates it with a permission mode. The modes are deny, allowlist, ask, auto, and full (documented on OpenClaw’s permission modes page). For a coding agent, auto is the sensible setting: allowlisted commands run without a prompt, and anything else goes through review before it asks you. If your mode is ask, OpenClaw pauses and requests approval before running apidog run; approve it once, or add the command to your allowlist so a read-only test against staging runs on its own. Set the mode under tools.exec in openclaw.json.
Step 4: Read the report inside OpenClaw
The -r cli reporter prints a step-by-step result in the terminal: each request, each assertion, and which one failed with expected versus actual value. That inline breakdown is what OpenClaw reads to decide its next step, so keep cli in the list.
When you want a report you can open in a browser or hand to a teammate, add the HTML reporter:
apidog run -t 1234567 -e 890123 -r cli,html
The html reporter writes a self-contained file to ./apidog-reports. Keep cli alongside it so OpenClaw still gets the inline output. For the JUnit format that CI dashboards parse and every other reporter, see the Apidog CLI test reports guide.
OpenClaw testing inside its own loop
The point is what happens when you stop asking and OpenClaw runs the scenario on its own because AGENTS.md told it to.
Picture OpenClaw 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 OpenClaw already runs your unit tests through. You wrote one instruction and the agent folded the command into how it already works.
This is the delegate-then-verify model that makes any agent workflow safe. OpenClaw 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 OpenClaw is actually running the CLI
Agents report success they did not earn, and OpenClaw is no exception. Three checks, in order of how often they catch problems.
First, confirm the command ran at all. OpenClaw’s transcript shows the exec commands it executed and their output. Look for the literal apidog run ... line and a result under it. If OpenClaw 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. Ask it directly:
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 OpenClaw, or a pipeline, treat the run as a clean gate. When the 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,” OpenClaw may have invented or misremembered an ID. Re-check the -t and -e values against AGENTS.md and the command Apidog generated in the CI/CD tab. The IDs in AGENTS.md are the truth.
Optional: connect the Apidog MCP server
Running apidog run through the exec tool covers most of what you need. One route goes further: the Model Context Protocol.
OpenClaw supports MCP servers. You add one with openclaw mcp add <name>, which writes the server definition into ~/.openclaw/openclaw.json under mcp.servers and accepts stdio flags like --command and --arg (see OpenClaw’s MCP documentation). The Apidog MCP server exposes your API specifications over MCP, so OpenClaw 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 OpenClaw gets it wrong
A few failures show up often during setup.
It ignores the AGENTS.md block. If OpenClaw runs a generic command or none at all, the file may not be loading into context. Confirm the block sits in the AGENTS.md that belongs to the agent’s active workspace, and remember that OpenClaw walks scoped AGENTS.md files by directory, so a rule buried in the wrong subtree gets skipped. Restarting the session forces a fresh read.
It never runs anything because exec is blocked. Since OpenClaw’s default policy tightened, exec can be denied or held behind an allowlist. If apidog run is silently skipped, check your permission mode under tools.exec and either switch to auto or add apidog to the allowlist. See the secure OpenClaw installation guide for how to open just this command without opening everything.
It passes an access token anyway. If OpenClaw 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 AGENTS.md; for the correct pattern, see Apidog CLI authentication.
It invents a flag. An “unknown option” error means OpenClaw 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 AGENTS.md and your verification step. When the summary and the exit code disagree, the exit code wins. If you have used another agent for this, the same rule holds; the approach mirrors what we cover in Apidog CLI in Codex and the differences in Claude Code vs OpenClaw.
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 workspace AGENTS.md, set the exec permission mode so the command can run, and OpenClaw 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 OpenClaw 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 OpenClaw 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 AGENTS.md, and watch OpenClaw pick it up on the next change. When you want the same gate in a pipeline without the agent present, Apidog CLI in GitHub Actions covers the secrets, reporters, and exit-code gating.
