What happened
The new repository publishes @cleanslop/cli, whose executable is cleanslop, under the MIT license. CleanSlop describes it as a tool for “readiness scans from your coding agent”: the client identifies the current GitHub repository and commit, starts a CleanSlop scan, can wait for the result, and returns the resulting report for the agent to act on. The basic invocation is npx -y @cleanslop/cli scan from a Git checkout whose HEAD has been pushed to github.com.
The CLI is explicitly designed to be installed into existing coding-agent environments. Its setup command can add a skill or rules for Claude Code, Cursor, and Codex. By default these are installed at user scope: a Claude Code skill, a Cursor rule, and a marker block in Codex's AGENTS.md. A project option writes the corresponding Cursor rules and AGENTS.md marker into the current repository. The command is described as idempotent, does not log in, and can show its intended changes without applying them. A separate remote MCP server is available, but it is not part of this CLI installation.
The operational loop is more specific than simply submitting code for a scan. scan initiates work and can wait; status polls a scan; and report fetches the cleanslop.report.v1 finding list in Markdown or JSON. A final Markdown report labels findings as confirmed or needing input, then asks whether to fix them, show them first, or defer. The README says the same prompt is available after a scan. Waiting defaults to eight minutes, respects a server-provided polling interval, and stops with an ETA and a follow-up command if the selected deadline is reached.
Authentication uses an RFC 8628 device flow. The client prints a verification URL and user code, stores pending state when asked not to wait, and states that it never prints the token. Credentials are stored in an OS-specific CleanSlop configuration directory with restrictive directory and file permissions; the tool refuses to write them inside the current Git worktree. whoami exposes only the connected login and token last four characters. The project also says it has zero runtime dependencies.
Open source does not make the scanning service itself a local or free product. The client includes commands to redeem promotional scan credits and to direct a human to billing, subscriptions, credit purchases, or cancellation through Stripe Link. The CLI does not receive the billing sign-in link. It can also initiate a named monthly plan, but the supplied material does not state plan prices or scan-credit pricing. The project says npm releases carry signed provenance.
What the archive adds
This is a new event, not an update to an earlier CleanSlop story. It sits beside recent open-source releases for coding-agent infrastructure: HumanLayer's core coding-agent platform and tstack's skills for Claude Code and Codex. CleanSlop differs by exposing a client for a hosted repository-scanning loop rather than a general agent platform or a reusable skill collection.
Trend signal
The release modestly supports Goal-scoped loops replace manual continuation. CleanSlop gives an agent a bounded external task—run a scan, wait, retrieve findings, and decide whether to fix them—rather than treating a chat response as proof of completion. It does not establish that the findings are reliable or that the full loop succeeds autonomously, but it shows a concrete attempt to make the stop condition and output externally observable.
Why it matters
Coding agents are increasingly able to edit a repository, but editing alone does not create a useful delivery loop. A repository-facing service becomes more operationally useful when the agent can invoke it in the same environment, retrieve a machine-readable result, and route ambiguous cases to a person. CleanSlop's client supplies those mechanics: setup instructions for popular coding agents, commands for status and reports, bounded polling, and explicit human-action paths for login and payment.
For teams, the important distinction is between evaluating the open-source client and trusting the hosted scanning service. The former can be inspected, pinned, and integrated into an agent harness. The latter still determines scan quality, data handling, availability, and cost. A small CLI can therefore be useful as workflow infrastructure without being evidence that its underlying review signal should automatically block merges or authorize large-scale automated fixes.
Limits and uncertainty
The supplied material documents commands and intended behavior, not independent scan-quality results. It does not say what categories a readiness scan evaluates, how findings are produced, what repositories or languages are supported, or the false-positive and false-negative rates. It also does not provide plan prices, included scan volume, service retention rules, or a complete account of what repository data reaches the hosted service. The repository is new and shows very limited visible adoption in the supplied snapshot. Signed npm provenance and local credential protections are useful implementation details, but they are not a full security assessment.
Skill to build now
Run a small evaluation before making any agent-triggered scanner authoritative. Choose one non-sensitive test repository with known issues, install the tool with its dry-run option, and run a scan. Compare each reported finding against the code and record whether it was actionable, ambiguous, or incorrect. If results are promising, have your coding agent consume the JSON or Markdown report but require a human review before accepting changes. This turns the release into a measurable feedback loop rather than another unattended tool call.
Reader takeaway
CleanSlop is making a hosted repository scan callable from Claude Code, Cursor, and Codex through an open-source CLI. Its real test is not whether an agent can launch a scan, but whether the returned findings are reliable enough—and governed carefully enough—to improve an engineering loop.
Open question
Will CleanSlop publish enough evidence about scan coverage, accuracy, pricing, and repository-data handling for teams to use the hosted service beyond experimentation?