githubnext / githubnext/gh-aw-cao
[aw-maintenance:compiler-security] github/gh-aw-actions: compiler exit 1 despite zero zizmor findings, plus stale lock file
- Dominant language
- JavaScript
- Stars
- 3
- Forks
- 1
- Avg merge
- 49m
- Merged PRs (30d)
- 837
Description
**Target repository**: `github/gh-aw-actions`
**Compiler exit code**: `1`
**Workflow sources checked**: `1`
**Generated lock files checked**: `1`
**Result**: `findings`
Compiling `daily-runtime-threat-scan.md` with the gh-aw compiler's full validation suite failed (exit 1), but the zizmor strict-mode step reported **0 security warnings/errors** while still being treated as a failure. This looks like a compiler anomaly (a strict-mode gate misfiring on a clean zizmor result) rather than an actual vulnerability, but it blocks a clean compile and must be resolved. Separately, the checked-in `.lock.yml` is stale relative to what the compiler now regenerates (399 insertions / 231 deletions), indicating the lock file needs to be recompiled and committed.
### Findings
| Tool | Workflow/Image | Severity | Finding | Remediation |
|---|---|---|---|---|
| gh-aw compile (strict mode) | `daily-runtime-threat-scan.lock.yml` | unknown | Compile exited 1 with message "zizmor found 0 security warnings/errors ... workflows must have no zizmor findings in strict mode" — contradictory (0 findings but treated as failure) | Investigate the strict-mode gate logic in the gh-aw compiler; if zizmor truly found 0 findings, this should pass. May be a compiler bug rather than a workflow issue. |
| gh-aw compile (drift) | `daily-runtime-threat-scan.lock.yml` | unknown | Checked-in lock file differs substantially from freshly compiled output (399+/231-) | Recompile `.md` sources with `gh aw compile` and commit the regenerated `.lock.yml` |
No actionlint, shellcheck, container, or license findings were reported in the captured output.
### Local fixing loop
1. Install or update the gh-aw extension, then configure the coding agent's MCP client to launch `gh aw mcp-server` over stdio from the target repository.
2. Give the agent the prompt below and require it to use the `fix` and `compile` MCP tools rather than editing generated `.lock.yml` files directly.
3. Require the agent to repeat the same full compiler validation and security scan until it passes, or stop and explain any finding that needs human action.
Agent prompt
Fix the reported gh-aw compiler and security findings in this repository. Change only `.github/workflows/*.md` sources and directly related files; never edit generated `.lock.yml` files. Use the gh-aw MCP server's `fix` and `compile` tools, rerunning compilation with strict validation, model checks, actionlint, shellcheck, yamllint, zizmor, poutine, runner-guard, grant, grype, and syft until clean. Review generated lock-file diffs, preserve existing behavior, and stop with a concise explanation if a finding cannot be fixed safely. If the strict-mode zizmor gate fails despite a report of 0 findings, investigate whether this is a compiler-tooling issue rather than a source-level fix, and document the outcome.
Raw evidence (redacted)
**summary.txt**
```
Target: github/gh-aw-actions
Exit code: 1
Workflow sources: 1
Compiled locks: 1
```
**git-status.txt**
```
M .github/workflows/daily-runtime-threat-scan.lock.yml
?? .github/aw/logs/
```
**diff-stat.txt**
```
.../workflows/daily-runtime-threat-scan.lock.yml | 630 +++++++++++++--------
1 file changed, 399 insertions(+), 231 deletions(-)
```
**report.txt**
```
✓ .github/workflows/daily-runtime-threat-scan.md (99.2 KB)
i Using actionlint 1.7.12
i Running actionlint (with shellcheck/pyflakes) on .github/workflows/daily-runtime-threat-scan.lock.yml
i Running zizmor security scanner on .github/workflows/daily-runtime-threat-scan.lock.yml
✗ zizmor failed
strict mode: zizmor found 0 security warnings/errors in daily-runtime-threat-scan.lock.yml - workflows must have no zizmor findings in strict mode
```
**result.json**
```json
{
"targetRepo": "github/gh-aw-actions",
"targetSha": "49459c75b37a0b82b4ecb15e1079972cc3353bc9",
"exitCode": 1,
"scanComplete": true,
"clean": false,
"reportDigest": "7623d94e0e6aba0a002ff36a74fa0041c3048546e24941ebe16c62a7eda3d058"
}
```
### Control Plane
- Correlation ID: `33834075588-34`
- Central repository: `githubnext/gh-aw-cao`
- Control plane run URL: https://github.com/githubnext/gh-aw-cao/actions/runs/33834075588
> Generated by [:shield: AW Maintenance / Compiler Security](https://github.com/githubnext/gh-aw-cao/actions/runs/33834411255) · copilot · auto · 15.2 AIC · ⌖ 8.62 AIC · ⊞ 13.9K · [◷](https://github.com/search?q=repo%3Agithubnext%2Fgh-aw-cao+is%3Aissue+%22gh-aw-workflow-call-id%3A+githubnext%2Fgh-aw-cao%2Faw-maintenance-compiler-security%22&type=issues)
> - [x] expires on Sep 18, 2026, 3:51 AM UTC
Contributor guide
Research direction
Start with .github/workflows/daily-runtime-threat-scan.md and its generated .lock.yml, then run gh aw compile with strict validation to reproduce the contradictory zizmor result. Inspect the compiler's strict-mode validation output and use the gh-aw MCP fix and compile tools rather than editing the lock file directly. Done means the validation passes with zero zizmor findings and the regenerated lock file is committed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, javascript
- Domain
- security, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100