New to Claude Skills? Learn how to install them →

microsoft on GitHub

Agent Host E2E Tests

OfficialFree

Streamline testing for agent host functionality.

Get this skill

Free · Opens the source repo

What Agent Host E2E Tests does

The Agent Host End-to-End Tests skill provides a structured approach to testing the agent host functionality within the Visual Studio Code environment. This skill is specifically designed for developers working with the agent host's end-to-end tests located in the src/vs/platform/agentHost/test/node/e2e directory. It leverages a black-box testing methodology that drives the entire agent host using the AHP protocol, ensuring that tests are executed against real server configurations and bundled SDKs.

This skill focuses on the use of recorded model traffic from YAML fixtures, allowing for deterministic and tokenless testing. It emphasizes the importance of replaying committed fixtures and provides a set of workflows for adding tests, recording new fixtures, and troubleshooting common issues. The skill is built around strict rules to ensure that tests are reliable and maintainable, such as the requirement for replay to be the default mode and the prohibition of hand-editing fixture contents.

Developers can utilize this skill to add cross-provider tests, re-record fixtures after SDK updates, and gate non-deterministic tests effectively. The comprehensive documentation, including a troubleshooting reference, guides users through the testing process, helping them to diagnose issues and maintain the integrity of their tests. This skill is particularly useful for teams working on multi-provider environments where consistent behavior across different models is crucial.

In summary, the Agent Host End-to-End Tests skill is an essential tool for developers looking to ensure the robustness of their agent host implementations through automated testing. By following the outlined workflows and adhering to the established rules, users can enhance their testing practices and improve the reliability of their agent host interactions.

When to use it

Use this skill when developing or maintaining end-to-end tests for the agent host in Visual Studio Code, especially in multi-provider scenarios.

When not to use it

This skill is not suitable for testing outside the agent host context or for scenarios requiring real-time interaction without deterministic replay.

What you can build with it

Adding a Cross-Provider Test

Create a new test for a specific behavior that spans multiple providers, ensuring consistent results across different models.

Re-Recording Fixtures After SDK Updates

Update your test fixtures when a new SDK version changes the expected behavior, ensuring your tests remain valid.

Troubleshooting Cache Misses

Diagnose and resolve issues related to cache misses during test runs by following the troubleshooting guidelines provided.

How to install Agent Host E2E Tests

View source

1. Install with the skills CLI

npx skills add microsoft/vscode/agent-host-e2e-tests --agent claude-code

2. Or install it manually

Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.

Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs

Inside SKILL.md

Written by microsoft

Agent host end-to-end tests

These tests run the whole agent host end-to-end (real server, real bundled provider SDK/CLI, real AHP protocol) while replaying recorded model traffic from committed YAML fixtures — deterministic and tokenless.

Before doing anything, read the architecture + troubleshooting reference: src/vs/platform/agentHost/test/node/e2e/README.md

It documents the mental model, the fixture format, every config flag, and a symptom→cause→fix troubleshooting table. This skill is only the workflows; the README is the source of truth for how it works.

Non-negotiable rules

  1. Replay is default and strict. No env var → serves committed fixtures, no token, no network. An unrecorded request is a hard cache miss that fails the run.
  2. A model-backed fixture's filename is derived from the test title (${provider}-${slug}.yaml). Renaming such a test orphans its fixture — re-record after any rename. Tests explicitly registered with hostOnlyTest(...) share captures/empty.yaml.
  3. Recording needs a real token (GITHUB_TOKEN or gh auth token) and talks to real CAPI. Only run it intentionally, with trivial/read-only prompts in temp dirs.
  4. Never hand-write or hand-edit fixture contents (especially not secrets/paths). Fixtures are always produced by recording; normalization/redaction is the proxy's job.
  5. Gate, don't fight. If a behavior can't replay deterministically, gate the test (see Workflow C) instead of loosening timeouts or the strict check.
  6. Track every disabled variant. Keep e2e/KNOWN_ISSUES.md current with the test title, scope, expected and observed behavior, and a focused reproduction command. For suspected product bugs, begin with a self-contained explanation in complete sentences of what the user is trying to do, what fails, and the likely user impact; define feature-specific terms instead of relying on test names or implementation details. Record symptoms, not speculative root causes.

Workflow A — Add a cross-provider test

  1. Add a test to the closest module under e2e/suites/, or create and register a focused suite module when the behavior is distinct. Use hostOnlyTest(context, ...) when crossing the model boundary would be a bug; otherwise use test(...). Drive turns with dispatchTurn(...) + context.client.waitForNotification(...); assert on AHP notifications, never on wall-clock timing.
  2. Keep the prompt minimal and deterministic (fewer model turns → smaller, more robust fixtures).
  3. Record fixtures for every enabled provider (Workflow B). Host-only tests need no per-test recording: the shared empty fixture remains strict and fails on any model request.
  4. Review the diff (Workflow B step 3), then run the test in plain replay mode to confirm it's green, then commit the test + fixtures together.

Provider-specific assertions go in that provider's *.integrationTest.ts after the defineAgentHostE2ETests(config) call.

Workflow B — Record / re-record fixtures

Re-record when you add a test, or when a bundled SDK/CLI bump changes its wire behavior (new endpoint, different turn count, changed tool schema).

  1. Ensure a token is available: gh auth token (or export GITHUB_TOKEN).
  2. Record per provider:
    AGENT_HOST_REPLAY_RECORD=1 ./scripts/test-integration.sh --run \
      src/vs/platform/agentHost/test/node/e2e/providers/claudeAgentHostE2E.integrationTest.ts
    
    Repeat for copilotAgentHostE2E / codexAgentHostE2E as needed.
  3. Review git diff on the fixtures: no local usernames/absolute paths, no tokens, no unreleased model ids. If something leaked, the fix is to extend normalization/redaction in capiReplayProxy.ts (_normalize + the *_RE redactors) and re-record — not to edit the fixture.
  4. Run plain replay (no env var) to confirm green, then commit.

If an SDK now hits a new ancillary/bootstrap endpoint (a probe, not a real model turn), add it to capiStubs.ts (served, not recorded) instead of recording it — see how /models/session is handled.

Workflow C — When a test can't replay deterministically

Real-time streaming, mid-turn aborts, and POSIX-specific local execution (shell tools, pwd, git worktrees) don't replay reliably. Gate them precisely so you keep coverage where it works:

  • Record-only (no deterministic replay at all): (RECORD ? test : test.skip)('…') — see can abort a running turn.
  • Subagent fixtures stale after an SDK bump: re-record them (AGENT_HOST_REPLAY_RECORD=1 …). Subagent flows are the most SDK-version-sensitive (parent + child share one /v1/messages sequence), but replay reliably once re-recorded, so no gating is needed.
  • POSIX-only (fails on Windows): gate with !isWindows, or a targeted per-provider flag when only one provider diverges. See the worktree and subagent-reopen tests.
  • Provider/OS-specific replay: add a targeted config gate that still permits recording and unaffected platforms. See the Codex shell-tool Linux gate.

Always add a comment explaining why the gate exists. Also add or update the corresponding entry in e2e/KNOWN_ISSUES.md. When the variant is enabled again, remove or update the entry in the same change.

Verifying & troubleshooting

  • Run a single provider in replay: ./scripts/test-integration.sh --run <path> (no env var).
  • Filter to one test: add --grep "<test title fragment>".
  • On a hang / timeout, read the runtime log first. For the Copilot provider, a failed test tails the most recent Copilot runtime (@github/copilot CLI) process-*.log into the test output ([agent-host-e2e] # … lines) — the SDK/CLI's own account of startup, auth, the model request, and the turn lifecycle. It runs at --log trace. A turn that never produced a model response, a panic, or an out-of-order/protocol error points at the SDK/CLI (re-record if a bump left the fixture stale; otherwise it's a real regression). Claude/Codex use their own runtimes and are not captured here. See the README's "A turn hangs or times out with no OS pattern".
  • For any failure (cache miss, missing fixture, per-OS timeout, leaked PII, subagent staleness, accidental real-CAPI contact), go to the Troubleshooting section of the README — it maps each symptom to its cause and fix.

Frequently asked questions about Agent Host E2E Tests

Similar skills