Audit a Laravel Repository per Customer Request

Your backend starts one session for each customer's repository and the agent works on its own clone. In a Laravel codebase like koel/koel the first files it opens are composer.json, composer.lock, package.json and, because the repository has one, AGENTS.md, whose Laravel Boost guidelines tell an agent to read the exact package versions before doing anything. It finds php >=8.3, laravel/framework ^13.0 locked at v13.37.0, required extensions such as ext-exif, ext-gd and ext-fileinfo, roave/security-advisories at dev-latest in require-dev, and a Vue front end managed by pnpm 10.32.1. It installs the PHP extensions the lock asks for, runs composer install, and then composer outdated --direct --major-only to list only the direct packages a major version or more behind. A constraint like predis/predis ~1.0, locked at v1.1.10, is the kind of row it checks against Packagist and reports with both versions.

Then it finds every test command the project defines, not just one. composer.json has "test": "@php artisan test --parallel", which runs PHPUnit through ParaTest; phpunit.xml.dist defines feature, unit and integration suites and sets DB_CONNECTION=sqlite with DB_DATABASE=:memory:, plus a long list of service keys blanked or faked for tests. The GitHub workflows run the same suite three ways (test-backend-sqlite.yml, test-backend-pgsql.yml, test-backend-mariadb.yml, all on PHP 8.3), and the front end has pnpm test (vp test) and pnpm typecheck (vue-tsc --noEmit). The agent runs php artisan key:generate the way the workflows do, then composer test, pnpm install --frozen-lockfile, pnpm test and pnpm typecheck, and records each command with whether it passed.

For risky patterns it reads the places Laravel apps usually go wrong and judges each one. Raw SQL is the first: whereRaw, selectRaw and DB::raw appear in app/Repositories/ (SongRepository.php, AlbumRepository.php, PlayRepository.php among them), and the agent checks each call for request input interpolated into the string instead of bound as a parameter. In a streaming app it follows the paths from PlayController, DownloadSongController and app/Services/Streamer/ to the filesystem, looking for a path built from the request. It checks unescaped Blade output ({!! !!}), mass-assignment guards on models, and routes registered without auth middleware. A hit that turns out to be safe, such as the {!! $slot !!} in the vendored mail template, is left out; each one kept has its file, line and reason.

The prompt forbids changing any file. The agent writes nothing back to the repository, and the setup it needs, from the generated app key to the SQLite database, stays in its own sandbox. Its final answer is the JSON with the three arrays.

The answer is the JSON, returned as the session's result and in the run.completed webhook's data.result when it is 16 KiB or less; past that, your server reads data.session_url with the key to get it. Because a Laravel app has two package managers, every outdated_dependencies entry names its ecosystem, so your product can group Composer and npm findings. The tests array has one entry per command, so a customer sees that composer test passed while pnpm typecheck failed, with the tail of the failing output beside it.

Your product checks the JSON before using it: three arrays, the expected fields, at most ten risky patterns. Anyone spot-checking an audit should confirm that each raw-SQL finding really involves request input rather than a constant, and that a test failure is not a missing PHP extension the sandbox could have installed. The transcript holds the composer outdated output, each test run and each file the agent opened, so a disputed line can be traced to its source.

A dev tool can re-run the audit whenever a customer's default branch moves. Your GitHub webhook handler sees the push, starts a session with the repository in resources and an Idempotency-Key made from the repository and the commit SHA, so a redelivered GitHub event returns the same run instead of starting a second. Keep the returned execution_id with the customer and commit in your database.

When the turn ends, Rush signs and POSTs run.completed to the key's webhook URL. Your handler checks webhook-signature, drops any webhook-id it has already processed (Rush retries with the same id), finds the commit by execution_id and stores the JSON next to it, so the customer sees the audit change commit by commit.

A Laravel test run needs PHP with the right extensions, Composer, Node, pnpm and often a database, and it executes the customer's code. Doing that for many customers on your own infrastructure means one shared machine running many strangers' code. Each Rush session is its own sandbox, so a customer's composer install, generated app key and test database exist only there.

Many customers can be audited at once, each in its own sandbox, up to the key's concurrent run limit, and each result is backed by a transcript of real commands. When a customer asks why a package is flagged or a test is marked failed, your support team opens the session and shows the command and its output instead of re-running anything.

Does the audit cover the JavaScript side of a Laravel app?

What if the PHPUnit suite needs MySQL or Postgres?

Why codex in the request instead of claude?

Can it run on a private customer repository?