OpenComputer test-coverage agent

This agent reviews recently merged GitHub pull requests, identifies one meaningful regression risk with weak test coverage, adds the smallest useful tests, runs the relevant test targets, and opens a test-only pull request.

It is deliberately narrower than a general coding agent. The configured repository is fixed in code, publishing rejects production-file changes, and the agent cannot merge a pull request or reuse an arbitrary branch.

How it works

Recent merged pull requests
           |
           v
Risk and missing-test review
           |
           v
Exact default-branch snapshot + private baseline
           |
           v
Minimal tests -> relevant test commands
           |
           v
Test-only audit -> deterministic branch -> pull request

Each run looks back seven days by default and selects at most one coherent gap. No material gap means no pull request.

Prerequisites

• Node.js 22 or newer
• access to an OpenComputer project
• a fine-grained GitHub personal access token scoped to one target repository with Contents: read and write and Pull requests: read and write
• a disposable or non-production repository for the first end-to-end run

The token is stored as an OpenComputer secret and injected only into the declared https://api.github.com/repos/ connection. It is never placed in a clone URL, shell environment, prompt, or repository file.

Repository archives are downloaded through GitHub's normal redirect to https://codeload.github.com. That redirect is declared on the same managed connection; it does not require another token or secret.

Configure the repository

Edit opencomputer/agents/test-coverage/tools/config.ts:

export const TARGET_REPOSITORY = {
  owner: "your-github-owner",
  repository: "your-repository",
  defaultBranch: "main",
} as const;

export const PUBLISH_ENABLED = false;

This mapping is code-owned. Prompts, pull-request bodies, commit messages, and repository files cannot redirect the agent to another repository.

Keep PUBLISH_ENABLED set to false for the first remote run. The agent still materializes the repository, adds and runs tests, and audits the final snapshot, but the publishing tool returns the proposed files without writing to GitHub. Set it to true only after reviewing that result against a disposable fixture repository.

Install and run in Development

npm ci
npm test
npm run typecheck
npm run opencomputer -- login
npm run opencomputer -- link
npm run opencomputer -- secrets set GITHUB_PAT \
  --environment development \
  --agent current
npm run deploy -- --watch

Start an explicit run in the development session:

npm run session -- "Review recent merged code and add the highest-value missing regression tests."

Keep the watch deployment running while testing. After any source change, wait for the new Development deployment and start a new session; an existing session remains pinned to the deployment with which it started.

To inspect a wider window, send a structured payload from the playground or session API:

{
  "lookbackDays": 14,
  "dryRun": true
}

dryRun: true still materializes the repository, permits local test edits and validation, and runs the final test-only audit, but does not create a branch or pull request.

Troubleshoot remote runs

egress-redirect-blocked while materializing

GitHub archive requests redirect from api.github.com to codeload.github.com. Current example source declares that redirect. If an older deployment reports a 502 egress-redirect-blocked error, pull the latest example, let npm run deploy -- --watch publish it, and start a new session.

Filesystem capabilities and launch trust boundary

This example explicitly enables the runtime-provided shell and read tools in both opencode.json and the agent render. It also allows every OpenCode permission inside the secure microVM, including access to external directories. The materialized repository lives under /workspace/repositories, outside OpenCode's working directory; without that permission, a headless session can wait indefinitely for an interactive approval when it first reads the checkout. The agent needs these capabilities after materialization to inspect the snapshot, edit tests, and run the repository's validation commands. If an older deployment reports Unknown tool: shell, Tool is not available for this request: read, No Code Mode tools are available, or stalls at the first read after materialization, pull the latest example, wait for the watch deployment, and start a new session.

These are deliberately unrestricted microVM capabilities: repository files and test scripts are untrusted code and may execute inside the session runtime, and filesystem access is not enforced as repository-only. The microVM isolates the host, but it does not make credentials, network access, or the target repository disposable. For the initial launch:

• use a disposable or non-production target repository;
• scope the fine-grained PAT to that repository only;
• keep PUBLISH_ENABLED set to false for the first run; and
• review the proposed files and command output before enabling publication.

The agent prompt confines shell and file-reading work to the exact materialized snapshot and reserves GitHub reads and writes for the audited code-defined tools. Those are behavioral guardrails, not a sandbox boundary. Do not target a sensitive or production repository until a constrained repository executor replaces the general-purpose filesystem tools.

Publishing boundary

The final tool compares the tested working snapshot with a private untouched baseline. It rejects:

• production, configuration, documentation, or other non-test changes;
• changed files omitted from the requested publish list;
• file deletions and symlinks;
• unchanged files and oversized changes; and
• paths outside common test, spec, fixture, and testdata conventions.

If the missing coverage requires a production-code testability refactor, the agent reports the blocker instead of expanding its write authority. Adapt the policy deliberately if your repository uses a different test layout.

Branches are deterministically named test/coverage-<head-sha>. Repeating a run for the same repository head returns the existing open pull request instead of creating a duplicate.

Every created pull request includes:

• risky behavior now covered;
• test files added or updated;
• exact validation commands and observed results; and
• why the tests materially reduce regression risk.

Local verification

npm test
npm run typecheck

This first version intentionally supports explicit runs only. Add a recurring schedule only after the repository-specific workflow and publication policy have been verified end to end.