[awf] sandbox: filesystem.allowWrite not enforced by AWF, only grants engine tool permissions #7616

Problem: sandbox.agent.config.filesystem.allowWrite is documented as restricting writes ("Paths outside these patterns are read-only") but is actually implemented as an additive permission grant, giving workflow authors a false sense of a write boundary.

Context: Reported in github/gh-aw#54371... wait, correction: github/gh-aw#54626. gh-aw v0.77.5, firewall 0.25.58.

Root Cause: pkg/workflow/claude_tools.go's appendSandboxWritableTools consumes AllowWrite only to append Read(p)/Write(p)/Edit(p)/MultiEdit(p) to the Claude engine's allowed-tools list. Nothing is emitted into awf-config.json's filesystem section, so AWF's own sandbox never enforces the boundary. Since the Claude engine's default allowed-tools already include unqualified Write/Edit, the path-scoped additions are strictly additive and cannot narrow anything.

Proposed Solution: This is primarily a gh-aw compiler issue, but AWF should support enforcing it: extend awf-config.json's filesystem schema/sandbox enforcement (chroot bind-mount read-only vs read-write, already partially implemented for /host mounts) to accept an explicit allowWrite allowlist so gh-aw can wire real in-kernel write restriction rather than relying solely on tool-permission lists. Coordinate with gh-aw to have it populate filesystem.allowWrite in the generated config, or update gh-aw's schema docs if enforcement is out of scope for AWF.

Generated by Firewall Issue Dispatcher · auto · 25.3 AIC · ⊞ 9.4K · ◷