Docs

Agent code scan

Scan the code the agent actually wrote, not the whole repository. It runs an external scanner over the agent working tree diff against your main branch, then joins each finding to the session that produced it and to what that session cost. A finding stops being "this file has an issue" and becomes "this run introduced this issue, in this session, for this much money".

Where to find it

  • Localhost: /agent-code-scan.html
  • API: GET /api/agent-code-scan
  • Sidebar: Guard, then Agent code scan

What it does for you

The diff, not the repository.Scanning everything buries what changed under everything that was already there. Scoping to the agent working tree diff against your main branch means the findings are about the work the agent just did, which is the only set you can act on while the context is still fresh.
Attribution, not just detection.Every finding carries the producing session and its cost. That answers the question a scanner alone cannot: which run did this, and was it a run you would have paid for if you had known.
A real scanner, not a reimplementation.It shells out to Semgrep OSS rather than rebuilding an analyzer. You get the upstream rule set and its maintenance, and RepoOps does the part that is actually missing, which is the join to the session.

Built vs. planned

The scan, the diff scoping, the session join and the cost attribution all ship today. Semgrep is external, so when it is not on the machine a built-in basic scan runs a handful of high-signal rules over the same diff and the tab says which engine produced the result, with the install command for the full rule set. A scan that could not run at all reads as did not run with its reason, never as a clean result. That distinction matters more here than almost anywhere else: an empty result from a scanner that never executed looks identical to a clean codebase, and only one of those is good news.

Last updated