Shahar Epstein
be28f7fe9c
* Tell agents to stop when breeze cannot run instead of using a host venv AGENTS.md said never to run pytest on the host but also listed `uv run --project` commands, and had no guidance for when breeze is unavailable. A sandboxed agent whose breeze calls were refused by the container gateway built a host virtualenv with Airflow 2.11.1 instead of reporting the failure. Narrow the host exception to the listed `uv run` commands, tell agents to stop and report when breeze cannot run, and document the breeze command for testing providers against a released Airflow version (generated from contributing-docs). Note in the magpie override that the breeze allows do not make breeze work behind the container gateway. * Record skill-eval run for the breeze-unavailable AGENTS.md guidance
4.1 KiB
Override: setup-isolated-setup-install — seed the breeze permission baseline
What this overrides
Augments the settings merge the setup-isolated-setup-install skill
performs (its "Golden rules → Do not overwrite an existing settings file
silently" desired-merge, and the project-local settings write in Step P).
When wiring the isolated / secure agent setup for this repo, add the
project-specific Bash permission allow-list below to the adopter's
project-local settings file (<repo>/.claude/settings.local.json) —
merged alongside the sandbox allowRead / allowWrite entries Step P already
writes there, surfaced in the same diff, and applied with the same approval.
This seeds a per-machine baseline at install time; it does not introduce a
committed project-scope .claude/settings.json. That path is committable here
— .gitignore ignores .claude/* but un-ignores !.claude/settings.json for
the apache-magpie plugin floor — so adding one is a deliberate project-level
change that belongs in its own PR, not a side effect of an install. Per-machine
settings belong in the ignored .claude/settings.local.json.
Permissions to add
Add each of these to permissions.allow (create the key if absent). Never
remove or reorder pre-existing entries — this is an additive merge, and an
entry already present is a no-op:
Bash(breeze *)
Bash(ANSWER=yes breeze *)
Bash(SKIP_BREEZE_SELF_UPGRADE_CHECK=1 breeze *)
Bash(SKIP_BREEZE_SELF_UPGRADE_CHECK=true breeze *)
Bash(SKIP_BREEZE_SELF_UPGRADE_CHECK= breeze *)
Bash(uvx *dev/breeze*)
Bash(uv run *dev/breeze*)
Bash(docker ps *)
Bash(docker info *)
Why
breeze is the mandated entrypoint for all local development in Apache
Airflow — the contributor instructions forbid running pytest / python /
airflow directly on the host (see this repo's AGENTS.md / CLAUDE.md).
Without these allows, every breeze invocation prompts for Bash permission,
which is pure friction for a command contributors run constantly.
- The
uvx/uv run *dev/breeze*forms cover the breeze shim that runs breeze fromdev/breeze(see ADR 0017). - The env-prefixed forms cover the common
ANSWER=yesandSKIP_BREEZE_SELF_UPGRADE_CHECKwrappers used throughout the dev/CI scripts.
Only non-destructive commands are allowed: breeze itself (which drives
docker internally, so its docker usage is covered by the single breeze call)
plus read-only docker ps / docker info. No docker rm, no
docker network prune, nothing that writes outside the breeze workflow —
those stay prompt-gated.
The allows only skip the permission prompt. They do not make breeze work
behind the magpie container gateway, which refuses Docker calls breeze
depends on (BuildKit sessions, untyped docker inspect) by design, so breeze
cannot run in a session whose DOCKER_HOST points at the gateway.
Scope notes
- These land in the gitignored, per-machine
.claude/settings.local.json, applied when a contributor sets up the isolated build — there is no shared committed settings file to review or maintain. - A contributor's own additional per-machine allows live in the same
settings.local.json; this override only seeds the breeze baseline and leaves everything else untouched.