Block the e2e stack targets, not just the ones that run the suite - #3
Merged
Conversation
Found by running the first real migration: an agent asked to run the e2e suite reached for `make start-e2e 2>&1 | tail -30`, which the guard allowed because it only knew the suite runners, not the targets that bring the stack up. Three things go wrong at once there, and the first is the one that wastes a session: The command never returns. start-app-e2e backgrounds the dev server with `&`, the server inherits stdout, and `tail` waits for an EOF that a live process never sends. It looks frozen and it is not: it is deterministic. It destroys data. start-supabase-e2e does `rm -rf` on the e2e database directory before recreating it, so an agent running it wipes a human's e2e session out from under them. It defeats the isolation. It brings up the SHARED stack on the fixed ports, which is exactly what the slot-leased isolated stack exists to replace, and what the slot offset added earlier was protecting. The matcher now keys on the `e2e` token in a make target rather than enumerating targets, so start / stop / test / supabase variants are all covered without the pattern growing a per-project list. Tests pin the four new cases plus four unrelated make targets that must stay allowed, so the broader match cannot quietly swallow `make lint`.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Found by the first real migration onto the plugin (atomic-crm#343). Asked to run the e2e suite, an agent reached for:
The guard allowed it, because the
e2ecategory only knew the commands that run the suite (npx playwright test,make test-e2e,e2e-smoke.sh), not the ones that bring the stack up. Three things go wrong at once, and the first one costs a session:start-app-e2ebackgrounds the dev server with&, the server inherits stdout, andtailwaits for an EOF a live process never sends. It looks frozen; it is deterministic.start-supabase-e2edoesrm -rfon the e2e database directory before recreating it, so an agent running it wipes a human's e2e session out from under them.e2e-smoke.shreplaces, and what the slot offset added earlier was protecting.Solution
The matcher keys on the
e2etoken in a make target instead of enumerating targets, sostart/stop/test/supabasevariants are all covered and the pattern does not grow a per-project list:/(npx\s+playwright\s+test|make\s+[\w:-]*e2e|e2e-smoke\.sh)/Still config-driven: drop
"e2e"fromvalidation.extraForbiddenand none of it applies, same as any other category.How to test
npm test395 tests green, 8 new. Four pin the newly blocked commands, including the exact one observed (
make start-e2e 2>&1 | tail -30). Four pin unrelated make targets that must stay allowed (make lint,make build,make install,make typecheck), so the broader token match cannot quietly swallow them.Worth noting what this does not change: a human typing
!make start-e2estill gets through, becausePreToolUsehooks do not fire on user-typed shell commands. That is the intended split, the guard gates agents and not the person at the keyboard.