cujo
Skip to content
Contents

What Cujo is

A reviewer that runs the pull request before it says anything about it, and what that does and does not buy you.

A diff shows what changed, not what happens

A reviewer that only reads the diff cannot see the test that now fails, the endpoint that now returns 500, or the install-time payload in a new dependency. It can guess. It cannot know.

Cujo reviews a pull request by running it. It clones the head into a disposable sandbox, runs the repository’s suite on base and on head, writes and runs its own probes against the changed code, boots the app and hits it, and — when the pull request adds a dependency — installs that dependency in isolation and records what the install did. The review it posts cites what happened.

What lands on a pull request

  • A reaction, within about a second of the delivery. It says Cujo has the pull request before it has anything to report, and it moves as the run does.
  • One review, from cujo-guard[bot]: a summary of what ran, the findings, and inline comments anchored to the lines they are about.
  • Nothing else. Cujo never posts APPROVE, so it cannot satisfy branch protection and wave a merge through, and it never comments on style, architecture or preference — every finding follows from something a sensor observed.

Every review posts unattended, including the ones that block a merge. The one human decision is the unlock: a maintainer lifts a block, and nothing else waits for anyone.

What it does not do

Stated here rather than at the back, because each of these changes whether Cujo is worth pointing at your repository.

  • Hold a credential where the code runs. The sandbox gets a tree and no token. A private repository is reviewed all the same: its base and head trees are fetched outside the box, with the App’s own access, and copied in. Its runs have pages too, for the repository’s owner signed in on this board; anyone else gets a 404.
  • Egress is metadata, never payload. The sandbox’s proxy records the host, the port and the byte count. It does not intercept TLS, so it never sees what was sent.
  • A process that opens a direct socket is not observed. The proxy sees what honours HTTP_PROXY, which is pip, npm, cargo, go and the common HTTP libraries. Something that deliberately bypasses it is a gap, and the reports say which sensors were watching so that gap is legible rather than silent.
  • It does not fix anything. Opening a remediation pull request is designed and not built.
The hard rules are tripwires, not proofs of absence. Each fires only on positive evidence a sensor recorded, so a sensor gap can cost you a finding and can never invent one. A false in a report means “not observed”, and everything downstream reads it that way.

Where to go next