Align compiler with gh-aw-firewall v0.28.6 (Cloud Hypervisor filesystem.allowWrite support)

[Copilot]

gh-aw-firewall v0.28.6 ships working filesystem.allowWrite support for the Cloud Hypervisor (CH) runtime, but the compiler's version gate was pinned below it, and activating it naively would have broken every CH workflow (workspace/HOME going read-only, planning failing closed on a missing host directory, and a mount-propagation bug present in v0.28.5).

Version gating

• Bump DefaultFirewallVersion v0.28.4 → v0.28.6.
• Add a CH-specific gate AWFCloudHypervisorFilesystemAllowWriteMinVersion = v0.28.6, distinct from the existing AWFFilesystemAllowWriteMinVersion = v0.28.5 used by Docker/gVisor — v0.28.5 has a mount-propagation defect that fails CH allowWrite on real hosts.

Runtime-aware default write paths

• ensureDefaultAgentWritePath now seeds /workspace and /workspace/.awf-home for Cloud Hypervisor in addition to the existing /tmp/gh-aw/agent, so the workspace export isn't narrowed to nothing and HOME (/workspace/.awf-home under CH) stays writable.

Host directory prerequisite

• The CH planner requires every allowWrite path to already exist on the host or it fails closed. The compiler now emits a mkdir -p for the affected host directories before the AWF invocation, e.g.:

mkdir -p "${GITHUB_WORKSPACE}/.awf-home" "/tmp/gh-aw/agent"

Quoting uses the existing shell-escaping helper that preserves ${GITHUB_WORKSPACE} expansion while safely escaping everything else.

Schema/docs

• Re-synced the allowWrite description in the embedded awf-config.schema.json to match the released v0.28.6 wording (now documents CH support).

Other

• Refreshed embedded container digest pins and regenerated all .lock.yml workflow artifacts to reflect the version bump.
• Added a changeset entry and unit tests covering the CH version gate boundary, the runtime-aware default write paths, and the emitted mkdir script.

• Fixes Align compiler with gh-aw-firewall v0.28.6 (Cloud Hypervisor filesystem.allowWrite support) #55169

---

Generated by 👨‍🍳 PR Sous Chef · gpt54 · 4.53 AIC · ⌖ 7.9 AIC · ⊞ 8.7K · ◷
_{Comment /souschef to run again}

[github-actions]

❌ Test Quality Sentinel failed during test quality analysis.

Warning

Threat Detection Engine Failure — The analysis engine could not complete. This is a tooling failure, not a security finding.

What happened

The threat detection engine failed to produce results.

Review the workflow run logs for details.

🧪 Test quality analysis by Test Quality Sentinel

[github-actions]

❌ Design Decision Gate 🏗️ failed during design decision gate check.

Warning

Threat Detection Engine Failure — The analysis engine could not complete. This is a tooling failure, not a security finding.

What happened

The threat detection engine failed to produce results.

Review the workflow run logs for details.

🏗️ ADR gate enforced by Design Decision Gate 🏗️

[github-actions]

⚠️ PR Code Quality Reviewer failed during code quality review.

Warning

Threat Detection Engine Failure — The analysis engine could not complete. This is a tooling failure, not a security finding.

What happened

The threat detection engine failed to produce results.

Review the workflow run logs for details.

🔎 Code quality review by PR Code Quality Reviewer

[github-actions]

🧠 Matt Pocock Skills Reviewer failed during the skills-based review.

Warning

Threat Detection Engine Failure — The analysis engine could not complete. This is a tooling failure, not a security finding.

What happened

The threat detection engine failed to produce results.

Review the workflow run logs for details.

🧠 Reviewed using Matt Pocock's skills by Matt Pocock Skills Reviewer

[github-actions]

❌ Ponytail Reviewer failed. Please review the logs for details.

Warning

Threat Detection Engine Failure — The analysis engine could not complete. This is a tooling failure, not a security finding.

What happened

The threat detection engine failed to produce results.

Review the workflow run logs for details.

Generated by Ponytail Reviewer for #55172

[Copilot]

Pull request overview

Aligns the compiler and generated workflows with gh-aw-firewall v0.28.6, enabling Cloud Hypervisor filesystem.allowWrite safely.

Changes:

• Adds runtime-specific version gating and writable defaults.
• Creates required host directories and expands tests/schema documentation.
• Refreshes firewall digests and generated workflow artifacts.

Show a summary per file

File	Description
pkg/constants/version_constants.go	Bumps AWF and adds the CH gate.
pkg/workflow/awf_feature_flags.go	Implements CH-specific feature detection.
pkg/workflow/awf_feature_flags_test.go	Tests version boundaries.
pkg/workflow/sandbox.go	Adds CH writable defaults.
pkg/workflow/sandbox_test.go	Tests CH defaults.
pkg/workflow/awf_config.go	Applies runtime-aware gating.
pkg/workflow/awf_config_test.go	Tests emitted CH configuration.
pkg/workflow/awf_command_builder.go	Adds host-directory preparation.
pkg/workflow/cloud_hypervisor_test.go	Tests generated preparation commands.
pkg/workflow/schemas/awf-config.schema.json	Documents CH support.
pkg/actionpins/data/action_pins.json	Adds v0.28.6 image pins.
pkg/workflow/data/action_pins.json	Updates embedded image pins.
.github/aw/actions-lock.json	Refreshes cached image pins.
.github/workflows/smoke-ci.lock.yml	Regenerates with v0.28.6.
.github/workflows/notion-issue-summary.lock.yml	Regenerates with CH write support.
.github/workflows/hippo-embed.lock.yml	Regenerates firewall pins.
.github/workflows/firewall.lock.yml	Regenerates CH configuration.
.github/workflows/example-permissions-warning.lock.yml	Regenerates CH configuration.
.github/workflows/daily-arxiv-researcher.lock.yml	Regenerates firewall pins.
.github/workflows/codex-github-remote-mcp-test.lock.yml	Regenerates CH configuration.
.changeset/bump-firewall-v0-28-6-cloud-hypervisor-allow-write.md	Records the shipped behavior change.

Review details

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

• Files reviewed: 20/304 changed files
• Comments generated: 0
• Review effort level: Balanced

[gh-aw-bot]

@copilot This PR is blocked by failing agent workflow runs and may need a follow-up pass. Please review the current failures and move the PR forward.

Failed checks:

• agent
• agent
• agent
• agent
• agent
• agent

Please also refresh the branch if needed and run the pr-finisher skill after addressing the failures.

Generated by 👨‍🍳 PR Sous Chef · gpt54 · 3.49 AIC · ⌖ 8 AIC · ⊞ 8.7K · ◷
_{Comment /souschef to run again}

[lpcox]

Root cause of the 6 failing agent checks

All other gates are green (unit tests, macOS/Windows builds, Windows integration, CodeQL, lint, WASM, Alpine). The 6 failures are gh-aw's own agentic workflows, and all six fail identically:

error mounting "/tmp/awf-<ts>/init-signal" to rootfs at "/tmp/awf-init":
make mountpoint "/tmp/awf-init": mkdirat .../merged/tmp/awf-init: read-only file system

awf-agent never starts, so docker compose up -d --pull never exits 1.

This is a genuine regression from this PR, not flakiness.

The chain

1. DefaultFirewallVersion → v0.28.6 now clears AWFFilesystemAllowWriteMinVersion (v0.28.5), so the filesystem gate opens for every runtime, not just Cloud Hypervisor.
2. Confirmed in this PR's regenerated Docker lock files, e.g. .github/workflows/test-quality-sentinel.lock.yml now emits:

   "filesystem":{"allowWrite":["/tmp/gh-aw/agent"]}

3. I ran that exact policy through the firewall's own applyFilesystemWritePolicy:

   /tmp:/tmp:rw                      →  /tmp:/tmp:ro
   <workspace>:<workspace>:rw        →  :ro            ← repo checkout read-only
   <initSignalDir>:/tmp/awf-init:rw  →  :ro
   (added) /tmp/gh-aw/agent:/tmp/gh-aw/agent:rw
   

4. runc applies mounts by destination depth, so the read-only /tmp bind lands first; creating the nested /tmp/awf-init mountpoint inside it then fails with EROFS.

Two separate defects

1. Firewall-side (github/gh-aw-firewall) — latent, newly exposed. This is the actual blocker.

src/services/agent-volumes/volume-builder.ts:66 builds alwaysWritableMounts from only agent-logs, session-state, and /dev/null. AWF's own control-plane mount ${initSignalDir}:/tmp/awf-init:rw is not exempt, and more importantly it is nested under the user-narrowable /tmp bind.

Note that simply exempting it is not sufficient — the failure is creating the mountpoint inside a read-only parent, so the mountpoint has to already exist or the destination has to move outside the narrowed tree. Consequence today: any allowWrite policy that does not include /tmp prevents the agent container from starting. The Docker path appears never to have been exercised live with such a policy.

I've filed this upstream with the fix options and their tradeoffs (the destination is baked into the published agent image's entrypoint.sh, so moving it needs a coordinated release).

2. Compiler-side — ensureDefaultAgentWritePath is only half-fixed.

sandbox.go now seeds /workspace and /workspace/.awf-home, but only under Runtime == AgentRuntimeCloudHypervisor. Docker compose still receives just /tmp/gh-aw/agent, so its workspace bind is narrowed to ro (line 2 of the output above) — the agent would be unable to edit the repo even once the mount bug is fixed.

My original issue said Docker was unaffected by Blocker 1. That was wrong, and this CI run disproves it — the same blast radius applies to the default Docker runtime. The workspace seeding should not be gated on the Cloud Hypervisor runtime.

Suggested sequencing

The firewall fix is a prerequisite: as it stands, bumping the default to v0.28.6 breaks every agentic workflow on the default Docker runtime. I'd hold this PR until the firewall ships the internal-mount fix, then bump to that version and widen the default allowWrite seeding to cover the workspace on all runtimes.

_{Analysis from the gh-aw-firewall side; reproduced locally against the released v0.28.6 policy code.}

[Copilot]

@copilot This PR is blocked by failing agent workflow runs and may need a follow-up pass. Please review the current failures and move the PR forward.

Failed checks:...

Investigated the failing agent runs — all six were plain Docker-runtime workflows failing identically at container start:

error mounting "/tmp/awf-<id>/init-signal" to rootfs at "/tmp/awf-init":
create mountpoint for /tmp/awf-init mount: mkdirat .../merged/tmp/awf-init: read-only file system

Root cause: bumping DefaultFirewallVersion to v0.28.6 crossed AWFFilesystemAllowWriteMinVersion (v0.28.5), so the always-seeded /tmp/gh-aw/agent default made the compiler emit filesystem.allowWrite for the Docker/gVisor compose runtimes for the first time. On those runtimes AWF enforces the policy by narrowing its own writable bind mounts to ro, turning the container rootfs read-only — so runc can no longer create the mountpoint for AWF's own /tmp/awf-init init-signal mount. The compose runtimes would also have had a read-only workspace and HOME, since only the CH runtime got the corresponding /workspace and /workspace/.awf-home entries.

Fix (9fdb35c): ensureDefaultAgentWritePath now seeds the implicit allowWrite entries only for runtime: cloud-hypervisor. Compose runtimes go back to emitting no filesystem section unless a workflow opts in explicitly, which is exactly the pre-bump behavior. Verified after recompile: CH lock files keep allowWrite: ["/tmp/gh-aw/agent","/workspace","/workspace/.awf-home"] plus the host mkdir -p, and Docker/gVisor lock files contain no allowWrite at all.

Also refreshed the branch against main (merge commit, lock-file conflict resolved by recompiling) and updated the tests, wasm golden fixture, and changeset.