Description
extractZipFile in pkg/cli/logs_download_zip.go:94 creates each extracted log file with the zip entry's own stored Unix mode (f.Mode()):
destFile, err := os.OpenFile(filePath, os.O_WRONLY|os.O_CREATE|os.O_TRUNC, f.Mode())
instead of a fixed, safe permission constant — the two MkdirAll calls in the same function (lines 68 and 77) correctly use constants.DirPermPublic (0o755), but the file-creation path has no equivalent. GitHub Actions log/artifact zips are produced inside containers that may run as a different UID and can store restrictive mode bits (e.g. owner-only read), which this extraction logic preserves verbatim. When that happens, files like access.log, gateway.jsonl, and rpc-messages.jsonl end up unreadable to whatever user later inspects /tmp/gh-aw/aw-mcp/logs/run-<id>/.
Expected Impact
This exactly matches a real, reproducible symptom: the Observability Coverage Report discussion from 2026-10-04 (#65447) reports Permission denied on every sampled run-<id> artifact directory, blocking firewall/MCP telemetry verification fleet-wide for that report cycle ("observability coverage cannot be positively confirmed"). Fixing the extraction permission makes downloaded log artifacts reliably readable, restoring the daily Observability Coverage audit (and any other tool reading downloaded run logs).
Suggested Fix
Use constants.FilePermPublic (0o644) for extracted regular files in extractZipFile, the same way unzipFile's sibling directory-creation calls already use constants.DirPermPublic, rather than trusting the zip entry's embedded mode.
Suggested Agent
An agent familiar with pkg/cli/logs_download_zip.go and the logs-download pipeline (see .github/skills/developer-internals/SKILL.md).
Estimated Effort
Quick (< 1 hour) — one-line permission fix plus a unit test asserting extracted files are world-readable regardless of the source zip entry's stored mode.
Data Source
DeepReport analysis — Observability Coverage Report discussion #65447 (2026-10-04), root-caused by reading pkg/cli/logs_download_zip.go:60-124.
Generated by 🔬 Deep Report · claude · agent · 548.3 AIC · ⌖ 12.8 AIC · ⊞ 7.1K · ◷
Description
extractZipFileinpkg/cli/logs_download_zip.go:94creates each extracted log file with the zip entry's own stored Unix mode (f.Mode()):instead of a fixed, safe permission constant — the two
MkdirAllcalls in the same function (lines 68 and 77) correctly useconstants.DirPermPublic(0o755), but the file-creation path has no equivalent. GitHub Actions log/artifact zips are produced inside containers that may run as a different UID and can store restrictive mode bits (e.g. owner-only read), which this extraction logic preserves verbatim. When that happens, files likeaccess.log,gateway.jsonl, andrpc-messages.jsonlend up unreadable to whatever user later inspects/tmp/gh-aw/aw-mcp/logs/run-<id>/.Expected Impact
This exactly matches a real, reproducible symptom: the Observability Coverage Report discussion from 2026-10-04 (#65447) reports
Permission deniedon every sampledrun-<id>artifact directory, blocking firewall/MCP telemetry verification fleet-wide for that report cycle ("observability coverage cannot be positively confirmed"). Fixing the extraction permission makes downloaded log artifacts reliably readable, restoring the daily Observability Coverage audit (and any other tool reading downloaded run logs).Suggested Fix
Use
constants.FilePermPublic(0o644) for extracted regular files inextractZipFile, the same wayunzipFile's sibling directory-creation calls already useconstants.DirPermPublic, rather than trusting the zip entry's embedded mode.Suggested Agent
An agent familiar with
pkg/cli/logs_download_zip.goand the logs-download pipeline (see.github/skills/developer-internals/SKILL.md).Estimated Effort
Quick (< 1 hour) — one-line permission fix plus a unit test asserting extracted files are world-readable regardless of the source zip entry's stored mode.
Data Source
DeepReport analysis — Observability Coverage Report discussion #65447 (2026-10-04), root-caused by reading
pkg/cli/logs_download_zip.go:60-124.