Description
Firewall-enabled workflow runs currently share a single sandbox-level access.log at /tmp/gh-aw/sandbox/firewall/logs/access.log. While this proves firewall logging is functional, zero of 5 sampled firewall runs had a per-run access.log attached to their workflow artifacts. Without a per-run artifact, there is no way to correlate network traffic to a specific run when debugging blocked calls or unexpected failures.
Suggested Changes
- Add an artifact upload step to firewall-enabled workflows that copies the per-run firewall log (or a snapshot of it scoped to the run) to the run artifacts directory
- Alternatively, configure the firewall sandbox to write per-run log snapshots to the standard
actions/upload-artifact path at the end of each run
- Ensure the upload happens even on failure (use
if: always() or equivalent in workflow markdown)
- Scope the artifact to the specific run ID to avoid cross-run contamination
Files Affected
.github/workflows/ — all workflows with firewall enabled (BYOK Ollama and similar)- Firewall sandbox configuration (if log path is configurable there)
Success Criteria
- Each firewall-enabled run produces an
access.log artifact in its run folder
- The artifact is scoped to the specific run and does not include entries from other concurrent runs
- The artifact is uploaded even when the run fails
- Observability report shows >0% coverage for firewall-enabled runs
Source
Extracted from Observability Coverage Report - 2026-07-25 discussion #47877: "5/5 firewall-enabled runs are missing per-run access.log under their downloaded run folders... The shared firewall log exists and is populated, but it is not captured per run, which limits correlation with a specific workflow execution."
Priority
High — zero observability for firewall-enabled runs limits debugging capability
🔍 Task mining by Discussion Task Miner - Code Quality Improvement Agent · sonnet46 · 54.2 AIC · ⌖ 8.34 AIC · ⊞ 7.2K · ◷
Description
Firewall-enabled workflow runs currently share a single sandbox-level
access.logat/tmp/gh-aw/sandbox/firewall/logs/access.log. While this proves firewall logging is functional, zero of 5 sampled firewall runs had a per-runaccess.logattached to their workflow artifacts. Without a per-run artifact, there is no way to correlate network traffic to a specific run when debugging blocked calls or unexpected failures.Suggested Changes
actions/upload-artifactpath at the end of each runif: always()or equivalent in workflow markdown)Files Affected
.github/workflows/— all workflows with firewall enabled (BYOK Ollama and similar)Success Criteria
access.logartifact in its run folderSource
Extracted from Observability Coverage Report - 2026-07-25 discussion #47877: "5/5 firewall-enabled runs are missing per-run access.log under their downloaded run folders... The shared firewall log exists and is populated, but it is not captured per run, which limits correlation with a specific workflow execution."
Priority
High — zero observability for firewall-enabled runs limits debugging capability