Hafiq Iqmal published a hands-on look at CPX v2 this week, and buried in his test results is the sentence that should reframe how we talk about this tool: when he ran cpx pint inside a fresh Laravel 13 demo, CPX used the Pint version that project had pinned. Not the latest release, not some globally cached build — the one the lockfile says the team agreed on. My position: that single behavior is worth more than everything CPX v1 did combined, and the old elevator pitch is now actively misleading.

The old pitch, for the record, was that CPX is to Composer what npx is to npm. It was a good pitch precisely because it required zero explanation. But it also framed CPX as a convenience wrapper: run a tool once, don't pollute composer.json, move on. Convenience wrappers are nice. They are also exactly the kind of thing that quietly rots your workflow, because 'run it once without installing it' usually means 'run whatever version happened to resolve today.'

Anyone who has debugged a formatting war knows the failure mode. Your local one-off Pint run reformats forty files. CI, running the project's pinned version, reformats them back. Nobody changed any code, but the diff churns, the pre-commit hook argues with the pipeline, and someone eventually pins the tool everywhere out of exhaustion — which defeats the whole point of an ephemeral runner. A one-off executor that ignores project pins isn't saving you an install; it's deferring a merge conflict.

The second v2 behavior Hafiq tested is cpx exec booting Laravel before running a throwaway PHP file. This scratches a real itch: the ten-line script that needs the container and your Eloquent models but absolutely does not deserve to become a registered Artisan command with a signature, a description, and a spot in your console kernel forever. Tinker covers the interactive case; this covers the 'I have a file, just run it with the app loaded' case. It's a small thing that removes a genuinely annoying ceremony.

Now the honest counter-argument, because it's a strong one: implicit context-awareness is magic, and magic cuts both ways. If cpx pint behaves differently depending on which directory you're standing in, then the same command is no longer the same command. A teammate pasting instructions into a chat can't know what your invocation will actually do. There's a reason plenty of developers prefer vendor/bin/pint precisely because it is boring and unambiguous — the path itself documents where the binary comes from.

I still land on the project-aware side, and here's why: the ambiguity was already there. The choice was never 'explicit versus implicit.' It was 'implicitly wrong versus implicitly right.' A v1-style runner that silently grabs an arbitrary version is every bit as magic as one that reads your lock — it just resolves the ambiguity against your project instead of for it. Defaulting to what the repository has pinned is the least surprising behavior available, because it matches what CI, your colleagues, and your deploy already do. If I want a specific other version, that should be the case that requires me to say so.

It also matters that this is now a Laravel-owned rewrite rather than a side project. Not because a logo makes code better, but because workflow tools live or die on maintenance: they sit in the path of every developer on the team, and an abandoned executor is worse than none. Stewardship by an organization with a paid team and a release cadence changes the calculus for adopting it in shared tooling docs, Makefiles, and onboarding guides — the places where you really don't want to write 'first, install this thing some guy stopped updating.'

So here's where I'd genuinely like to hear from you, because my sample size is my own projects: would you let a context-aware runner like cpx pint into your CI and your contributor docs, or do you draw the line at scripts in composer.json and the explicit vendor/bin path — and if it's the latter, is that a real reproducibility concern, or muscle memory from years of tools that guessed wrong?