DeepSeek Harness is a loop. The agent reads your workspace, edits files, runs commands through its bash tool, and decides what to do next based on the output. So why aren’t your API tests in that loop? They sit in Apidog behind a GUI and run when someone remembers to click. The 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 DeepSeek Harness knows it exists, the 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.
There is also a token argument for doing this. An agent that confirms your API still works by re-reading handler code and reasoning about response shapes burns context on every pass. An agent that runs one command gets ground truth back in a few lines. The CLI compresses “is the API correct?” into an exit code, and the agent spends its context on the fix instead.
This guide covers the harness-specific part the generic install guide skips: which instructions file DeepSeek Harness actually reads, how its bash tool executes apidog run, and how to keep the loop honest. 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 machine is authenticated.
Which DeepSeek Harness this is about
DeepSeek Harness, dsh on the command line, is the open-source agent harness DeepSeek released on August 13, 2026, alongside V4-Pro on the API. It is MIT licensed, sits at github.com/deepseek-ai/deepseek-harness, and had climbed past 169k stars as of August 20. You start it with npx @deepseek-ai/dsh web, which serves a local web UI at http://127.0.0.1:3080. There you pick a workspace, the project directory where you launched it, and the agent works inside it: reading and editing files, running commands, and asking before operations that require approval under the active permission policy.
Two things shape everything below. First, the harness is a developer preview. The README warns, in capitals, that there will be compatibility-breaking changes, so treat file names and config keys here as accurate for late August 2026 and re-check against the repo docs if something does not load. Second, everything in dsh is a plugin, built on the Cordis architecture, which makes the practical question below answerable: which plugin reads your project rules, and what does it look for? For the wider tour, see what DeepSeek Harness is; for how it stacks up against the incumbent, see DeepSeek Harness vs Claude Code.
Step 1: put the CLI in AGENTS.md
DeepSeek Harness reads workspace instructions through its @deepseek-ai/dsh-agent-instructions plugin, and the defaults are friendly if you have used other agents. Per the plugin’s source and the config catalog, the loader walks upward from the session’s working directory to your project root (marked by .git) and loads AGENTS.md, falling back to CLAUDE.md, in each directory along the way. Local overlays named AGENTS.local.md or CLAUDE.local.md load after the base files, and a fixed user-global AGENTS.md in $DSH_HOME (defaults to ~/.dsh) applies across projects. Files over 1 MiB are ignored, which your rules file will never approach.
The practical upshot: if your repo already has an AGENTS.md for Codex or a CLAUDE.md for Claude Code, DeepSeek Harness picks it up with zero extra setup. Add a short Apidog block to it:
## API testing with the Apidog CLI
- To test the API, run the Apidog scenario. Do not click through the GUI.
- Command: apidog run -t <scenario_id> -e <env_id> -r cli
- Exit code 0 means every assertion passed. Non-zero means a failure; read the report and fix the code.
- The machine is already authenticated. Never add an --access-token flag and never put a token in this file.
This is why the rules file beats chat. A scenario ID typed into the session composer disappears when the session ends. One written into AGENTS.md loads into every new session, for every teammate, on every machine that clones the repo. If you work across several projects, the user-global ~/.dsh/AGENTS.md carries the habit (“always verify API changes with the project’s apidog run command”) while each repo’s own file carries the real IDs.
Step 2: get the command from Apidog
You do not have to guess the scenario and environment IDs. Open the test scenario in Apidog, go to its CI/CD tab, and copy the generated command. It looks like this:
apidog run -t 123456 -e 789012 -r cli
The -t flag is the test scenario ID, -e is the environment ID, and -r cli selects the reporter that prints results inline, which is exactly what an agent needs to read. Paste the real IDs into your AGENTS.md block so the agent runs the command Apidog generated, not a guess.
Step 3: have the agent run the test
Start a session in the dsh web UI with your workspace selected. The instructions loader has already fed your AGENTS.md into the agent’s context, so it knows the CLI exists. Make a change that touches your API, or just ask:
Run the Apidog test scenario and tell me the exit code.
The agent executes it through its bash tool, and knowing how that tool behaves saves you a debugging session later. Per the tool catalog, the default bash tool runs each command in a fresh shell: no working directory, variables, or functions persist between calls, and commands run from the session workspace unless a workdir is passed. Fine for apidog run, a single self-contained command, but the agent cannot cd somewhere first and run the test as a second step. If your scenario must run from a subdirectory, put the full invocation on one line in your rules file.
Two more behaviors worth knowing. Non-zero exits come back as an explicit [exit code: N] marker, so the pass/fail signal survives even when long output gets truncated to its tail. And commands may run under a file sandbox: a blocked operation is reported as a policy denial, not a command failure. A read-only test run rarely trips this, but the HTML reporter writing to ./apidog-reports could, depending on the active policy.
Whether the run needs your click first depends on that same permission policy. The web UI asks before operations that require approval under it, per the user guide. When it prompts for apidog run, approve it: a test scenario against staging is exactly the kind of safe, read-mostly command the approval flow exists to wave through.
Step 4: read the report
When a run goes red, the report has the answer. With -r cli, the agent gets a readable breakdown inline: 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 agent to locate the fix without you translating.
For a report you can open in a browser or hand to a teammate, add the HTML reporter:
apidog run -t 123456 -e 789012 -r cli,html
The html reporter writes a self-contained file to ./apidog-reports. Keep cli in the list so the agent still gets the inline output it reads to decide its next step.
The loop, end to end
Here is what the setup buys you. Say the agent is editing a checkout handler. Without the CLI, its loop ends at “the code looks right.” With the block in AGENTS.md, the loop extends: it edits the handler, runs apidog run -t 123456 -e 789012 -r cli, and reads the result. Green, it moves on. Red, it sees [exit code: 1], reads which assertion failed (a 500 where a 200 was expected, a missing total field, a wrong currency code), patches the handler, and re-runs. The API contract check becomes part of the same edit-test-fix cycle the agent already runs your unit tests through.
Notice what the agent did not do: re-read every route file to convince itself the API works. The scenario already encodes the expected behavior, built visually in Apidog by whoever owns the API. The agent delegates verification to a deterministic tool and spends its tokens where judgment is needed. That division of labor is the whole pattern: dsh writes code, the CLI verifies the API layer, and you author scenarios in Apidog without writing test code at all.
Verify dsh actually ran it
Agents report success they did not earn, and a developer-preview harness is not the place to take prose on faith. Three checks, in the order they catch problems.
First, confirm the command ran. The dsh web UI shows the agent’s tool calls and their output in the session. Look for the literal apidog run ... bash call and its result. If the agent says it ran the tests but no such call appears, it summarized something it never did. Ask it to run again and show raw output.
Second, confirm the exit code. Ask directly: “what was the exit code of that apidog run command?” The harness hands the agent an explicit [exit code: N] marker on failure, so there is no ambiguity to hide behind. When the agent’s summary says “tests passed” but the marker said non-zero, the marker is right.
Third, confirm it used the real scenario. A “scenario not found” failure usually means the agent invented or misremembered an ID. Re-check the -t and -e values against your AGENTS.md block and the command in Apidog’s CI/CD tab. The IDs in the rules file are the truth; anything else the agent typed is a guess.
Optional: add the Apidog MCP server for spec access
Running scenarios covers verification. If you also want the agent to read your API specification while it writes code, that is a job for MCP, and here the honest picture matters: as of late August 2026, MCP support is not documented in the DeepSeek Harness core README or user guide. What exists is a community plugin, hyqhyq3/dsh-mcp-manager, discovered through the dsh-plugin GitHub topic like the rest of the ecosystem. It adds an MCP page under Settings, supports remote HTTP and local stdio servers, registers tools as mcp__<name>__*, and reads per-project server definitions from <workspace>/.dsh/dshmm/mcp.json.
Through it you can connect the Apidog MCP server, which exposes your API specifications over MCP so the agent can check the actual schema of an endpoint before writing the handler, instead of after the scenario fails. Community plugin plus developer-preview host means this pairing can break on either side’s update, so treat it as a bonus layer. The CLI path above is the load-bearing one: it needs nothing but a shell.
Preview caveats, and where this goes
DeepSeek Harness moves fast and warns you it will break things. The specifics most likely to shift are the ones named here: the instructions plugin’s file candidates, the bash tool’s sandbox reporting, and anything the community MCP plugin touches. The pattern, though, is portable. A rules file that says “verify the API with this one command” plus a CLI that returns a clean exit code works in dsh today for the same reason it works in Claude Code and every other harness in this series: agents are good at reading command output and bad at being trusted without it.
So: download Apidog, build one test scenario visually, copy its apidog run command from the CI/CD tab, and drop the block into the AGENTS.md your repo probably already has. The next time DeepSeek Harness touches your API code, it will check its own work before telling you it is done.
FAQ
Does DeepSeek Harness read AGENTS.md natively? Yes. The @deepseek-ai/dsh-agent-instructions plugin loads AGENTS.md (or CLAUDE.md as a fallback) from your project root and the directories above your session’s working directory, plus AGENTS.local.md/CLAUDE.local.md overlays and a user-global AGENTS.md in ~/.dsh. If you already keep an AGENTS.md for other agents, dsh picks it up unchanged.
Do I need a paid DeepSeek plan to use the Apidog CLI in dsh? No. The harness is MIT-licensed open source, and you bring your own model: catalog providers cover Anthropic, OpenAI, Bedrock, Vertex, and Azure, and custom gateways work through settings.yaml, as covered in how to run any model in DeepSeek Harness. The Apidog CLI itself is a free npm package; it needs an Apidog test scenario and authentication, not a specific model.
Why does the agent’s second command forget the directory the first one changed to? By design. The default dsh bash tool runs every call in a fresh shell, so cd does not persist between commands. Pass the tool’s workdir parameter or, simpler, keep the full apidog run invocation on a single line in your rules file so there is nothing to forget.
Can dsh run the scenario without asking me every time? That depends on the active permission policy. The web UI asks before operations that require approval under it; the user guide does not enumerate the policy levels, so check Settings in your build to see what your deployment allows. When it does prompt, approving an apidog run against staging is a safe yes.
