Preconfig Now Checks Agent Setup Files on Every Pull Request

A setup file for a coding agent breaks quietly. Someone bumps Python in the dev container and forgets the Copilot workflow, or edits the generated setup script by hand, and nobody finds out until an agent spends its first ten minutes failing to install a package. Preconfig 0.3 moves that discovery to the pull request.

It ships as a GitHub Action, added to a workflow like this:

on: pull_request
jobs:
  preconfig:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: Preconfiguration/[email protected]

What It Does on a Pull Request

The action downloads the release for the runner and checks it against the release’s checksums before running anything. Then it runs preconfig check. Each problem shows up as a mark on the line it’s about, in the pull request’s file view, and a table of all of them goes into the job summary. A Cursor environment file with a key Cursor doesn’t read, a setup script that no longer matches preconfig.yaml, an Ona task with no command: each one lands where the reviewer is already looking.

When the pull request touches preconfig.yaml or the setup script, the action also runs preconfig verify. That starts a clean Ubuntu container, runs the whole setup and then the project’s own ready check, usually its tests. If the machine doesn’t come up ready, Preconfig Doctor reads the log and the job summary says which step failed and why.

Verify doesn’t run on every pull request. It takes minutes, and a change to the README can’t break the machine.

A Warning When Preconfig Itself Gets Old

The platforms change their setup formats every few months. Preconfig keeps what it knows about them in one place, with the date it was last checked. From 0.3, preconfig check warns when that date is more than 60 days old. A team that pinned an old release gets told, instead of passing checks against formats the platforms have since changed.

What the Reviews Caught

Two independent reviews went through the action before release. The one that mattered most: on pull_request_target, a workflow trigger that carries the repository’s secrets, verify would have run a stranger’s setup script with them. The action now refuses to run verify there and says why. Others: marks pointing at the wrong file when the project lives in a subfolder, and a pin to a commit quietly downloading whatever release was newest.

The action’s own test caught one more after 0.3.0 went out. On Windows runners, git checks text out with Windows line endings, and check read every generated file as changed. Version 0.3.1 fixed it the same afternoon, and the test now runs with the runner’s own git settings on Linux, macOS and Windows.

Everything else stays as it was. Download 0.3 for Linux, macOS or Windows, or just add the action.