fix: unblock sandboxed worktree setup, stop E2E dirtying the tree, guard pushes server-side

[johanzander]

Three environment problems reported after a worktree session stalled. Each has a measured cause, not a guessed one.

1. The sandbox blocks the caches worktree-setup.sh writes

sandbox.filesystem.allowWrite was [".", "~/GitHub/bess-manager"]. Writes are allowOnly, and the Playwright browser cache is not in it:

mkdir ~/Library/Caches/ms-playwright/probe -> Operation not permitted

Probing turned up a second cache with the same shape: ~/.npm/_cacache. Only ~/.npm/_logs is granted by default, so npm can write its log and not its cache — breaking npm install in worktree-setup.sh and npm ci in run-e2e.sh.

Neither failure names the sandbox, which is why this cost a whole worktree setup:

• npm reports EPERM as "Your cache folder contains root-owned files … please run: sudo chown -R 502:20 ~/.npm" — a guess. Nothing is root-owned, and sudo is on the ask list.
• Playwright's step is bounded by worktree-setup.sh's own timeout, whose message blames a slow download — indistinguishable from the real Speed up local verification: cache/symlink worktree dependencies instead of reinstalling #556 hang.

Both caches are added to allowWrite, probed by verify-sandbox.sh, and both scripts now say what the error actually means.

Sandbox policy is captured once, at session start. This takes effect in a fresh session; verify-sandbox.sh confirms it there.

2. E2E wrote settings back into a tracked file

e2e/ci-wizard-settings.json lived beside the real fixtures but is pure runtime scratch. Every consumer — run-e2e.sh:96 and all 14 wizard steps in ci.yml — does echo '{}' > it immediately before mounting, precisely so the wizard triggers fresh. Nothing ever read the committed content. The container then wrote the wizard's result back through the read-write mount, dirtying the tree after every local run.

Untracked and gitignored. No consumer changes, because every one already creates the file.

The real ci-bess-settings*.json fixtures do have content that matters and still write back. That mount has to stay read-write — it is how the app persists settings — so :ro would break the wizard rather than protect the file. Documented in the verify skill, not changed here.

3. git push is guarded server-side instead of by a prompt

The blanket Bash(git push*) ask existed because prefix globbing cannot reach a marker at an arbitrary argument position. But the glob was compensating for having no guard at the only layer that sees a ref update rather than a command string.

Four GitHub rulesets now refuse those spellings, all enforcement=active with empty bypass_actors:

Repo	Ruleset	Applies to	Rules
bess-manager	Protect Main Branch (pre-existing)	~DEFAULT_BRANCH	deletion, non_fast_forward, pull_request
bess-manager	Protect beta release branches	beta-release-*	deletion, non_fast_forward
bess-manager	Protect release tags	~ALL tags	deletion, non_fast_forward
bess-manager-beta	Protect beta main	~DEFAULT_BRANCH	deletion, non_fast_forward

The empty bypass list is load-bearing: local pushes authenticate as the repo owner (osxkeychain; gh auth status → johanzander), never as bess-agent. A ruleset exempting admins would exempt every push this machine makes.

Accepted residual: force-pushing or deleting a feature branch (fix/**, feat/**) stays possible. Bounded to an unmerged branch, and it keeps ordinary work prompt-free.

Tag creation stays allowed so release can tag; only deletion and force-update are blocked. Removing a mistaken tag now needs a deliberate ruleset edit.

quality-check.sh pins push in MUST_NOT_BE_GUARDED, so the prompt cannot be reinstated out of caution.

⚠️ The pending beta GHCR migration force-pushes main to beta/main, which the new rule refuses. CLAUDE.md documents the disable → push → re-enable recipe. Do not add a bypass actor for it.

Verification

• scripts/quality-check.sh — 0 errors, 0 warnings (76 command shapes checked)
• verify-sandbox.sh — both new probes correctly FAIL against the old captured policy, proving they detect the condition
• Pushing this branch ran unattended, confirming the rule change

Out of scope — found while investigating

The Playwright install hang is reproducible and version-specific. Playwright 1.59.1 (pinned in e2e/package.json) stalls twice at exactly 84 files / 448K, unsandboxed, with the download already complete (173MB in $TMPDIR) and oopDownloadBrowserMain.js idle at 0% CPU with every libuv worker parked in __psynch_cvwait. Playwright 1.62.1 completed cleanly on the same machine, same network, minutes apart. So it is extraction, not the network — and bumping the pin looks like the actual fix.

Note there is no issue tracking this hang. worktree-setup.sh cites #556, but only as the work it was first observed during; #556 itself is the closed "Speed up local verification: cache/symlink worktree dependencies" issue. This PR drops that shorthand and records the measurement in CLAUDE.md instead.

The bump is not done here: it moves the E2E runner under 14 CI wizard scenarios and deserves its own PR.

[bess-agent]

@claude-bot review

[bess-manager-claude-bot]

Summary

Self-reported (no linked issue) — three environment problems each backed by measured evidence in the PR body (sandbox EPERM traces, git-diff dirtying, push-guard gap analysis). This is the PR's second review round; the last commit (8a1971d) already addressed 5 findings from a prior /code-review plus one from #637's review, including correcting an earlier false claim that GitHub rulesets cover release-X.Y branch deletion (they don't — now honestly disclosed as a residual gap).

Verified independently:

• e2e/ci-wizard-settings.json deletion: confirmed via git grep that every consumer (14 ci.yml steps + run-e2e.sh:96) truncates it to {} before mounting — nothing reads the committed content, so deleting it and adding it to .gitignore is safe.
• scripts/quality-check.sh's embedded python permission-gate: extracted and ran it standalone against this branch's .claude/settings.json — passes clean (76 command shapes checked, 20 require deny, 26 must stay unattended), confirming MUST_NOT_BE_GUARDED/MUST_BE_GUARDED/MUST_BE_DENIED are consistent with the actual settings diff (the git push* ask lines are correctly gone from ask, and re-asserted as required-unattended).
• scripts/worktree-setup.sh's new install_matches_lockfile() python heredoc: ast.parse clean, logic checked — compares package-lock.json vs node_modules/.package-lock.json per-package version, skips optional deps (correctly, to avoid false STALE on fsevents-only installs), and defaults to "matches" when either file is missing/unparseable (documented as intentional — no evidence, no forced reinstall).
• All three touched shell scripts pass bash -n. The lone shellcheck hit (SC2001, quality-check.sh:455) is on an untouched pre-existing line, not introduced by this diff.
• release-X.Y residual: cross-checked against .claude/skills/release/SKILL.md steps 92–98 — the branch name matches exactly, and step 97 already requires "explicit user approval before each push/tag/release," so the disclosed gap (unguarded at both local-ask and GitHub-ruleset layers) is mitigated in practice by an existing manual approval gate, not silently open.

One thing I could not verify: the entire safety case for removing the blanket Bash(git push*) ask rests on four GitHub rulesets (Protect Main Branch, Protect beta release branches, Protect release tags, Protect beta main) actually existing with enforcement=active and an empty bypass_actors list. gh api repos/johanzander/bess-manager/rulesets is permission-gated for this bot and I could not run it. Since this is the load-bearing claim of the PR — if the rulesets aren't exactly as described, git push --force/--delete on protected refs becomes unguarded at both layers — please confirm with gh api repos/johanzander/bess-manager/rulesets and gh api repos/johanzander/bess-manager-beta/rulesets before merging. Given this is already the second review pass and the PR explicitly names this as the verification step (and states "pushing this branch ran unattended, confirming the rule change"), I'm not blocking on it, but it's worth a manual confirm since I structurally can't do it.

Scope: minimal and on-topic — sandbox permissions, .gitignore, script docs/comments, and the worktree lockfile-staleness fix. No unrelated code touched. No Python/TS source under core/, backend/, or frontend/ is touched, so most of the architecture/API-layer checklist doesn't apply here.

Rule violations: none found.

No blockers — approving.