[aw-compat] Daily gh-aw compatibility audit: 20 repos, 3 real issues, 3 audit artifacts (2026-08-03)

[github-actions]

Daily gh-aw cross-repo compatibility summary

Run: 2026-08-03-10-02-19-555 · gh-aw build under test: 5325893 (local make build, not gh aw fallback)

At a glance

Metric	Value
Repos selected (by stars)	20
Clone failures	0
Repos with a post-fix compile failure	6
— of which real compatibility/config issues	3
— of which audit-methodology artifacts (not real bugs)	3
Files changed by gh aw fix --write across all repos	303

Discovery method changed this run (read first)

gh search code (GitHub Code Search) returned either HTTP 429 or 200-with-null-fields for every query this run — confirmed via both gh search code and a raw gh api search/code call, so it isn't a query-specific fluke. Repository discovery fell back to enumerating repos in orgs known to dogfood gh-aw (githubnext, github) plus the triggering actor's own repos, verifying real gh-aw usage via contents/.github/workflows (*.lock.yml presence) instead of full-text search. This produced 22 verified candidates rather than the usual 60+, so today's sample skews toward githubnext/github-owned repos rather than a broad external one. Worth checking whether code search is expected to work in this environment.

3 repos fail only because of this audit's --strict flag — not real bugs

github/gh-aw-mcpg, github/gh-aw-firewall, githubnext/gh-aw-test each set strict: false on purpose in specific workflow files, which are e2e/smoke tests asserting that internal-only fields (sandbox.mcp.container, sandbox.agent.args, sandbox.agent: false) get rejected under strict mode. This job's baseline step always runs compile --strict, which overrides that per-file setting and manufactures a failure that doesn't exist under the repo's own configuration (verified by recompiling the identical files without the forced flag — all succeed). No gh-aw change needed; flagging so "6 failing repos" isn't misread as 6 real bugs, and so a future run of this same audit considers respecting each workflow's own strict: setting instead of forcing it everywhere.

3 genuine, low-frequency issues (each 1 occurrence — below this workflow's 2-repo bar for a dedicated codemod issue)

1. `tools.github.toolset` typo (singular) — githubnext/gh-aw-trial-oxpecker-test

error: Unknown property: toolset. Did you mean 'toolsets'?

The validator already names the fix, but gh aw fix --write has no codemod for it — unlike the sibling timeout_minutes → timeout-minutes and add-comment.discussion → add-comment.discussions codemods, both of which fired correctly elsewhere in this same run. Cheap codemod candidate since the correction is unambiguous, but only 1 instance seen this run (and none in the 61-row rolling history), so not escalated to its own issue yet.

2. allowed-repos: current invalid alias — pelikhan/github-agentic-workflows

error: 'allowed-repos': value must be one of 'all', 'public', '${{ github.repository }}'

current reads as a very natural value for "this repo" but isn't accepted. Consider documenting/accepting it as an alias for ${{ github.repository }}.

3. update-project missing required project — githubnext/aw-chat-transcripts

error: 'update-project': missing property 'project'. Expected format: {"project":"string",...}

No inferable default, so not a codemod candidate — but the error message could point more directly at a worked example.

References

• githubnext/agentics (879★) — compiled clean
• github/gh-aw-mcpg (153★) — 3 pre-existing e2e fixtures fail only under forced --strict
• pelikhan/github-agentic-workflows (8★) — allowed-repos: current

Full per-repo logs, diffs, and raw results are in cache-memory under aw-compat/runs/2026-08-03-10-02-19-555/.

Generated by 🔧 Daily AW Cross-Repo Compile Check · agent · 271.2 AIC · ⌖ 31.4 AIC · ⊞ 7K · ◷

• expires on Aug 10, 2026, 2:27 AM UTC-08:00