Summary
During the daily 20-repo compatibility audit, two independent public repositories hit the same unresolved compile-time incompatibility, and gh aw fix --write does not offer a codemod to address it.
Pattern
Workflows set engine.id: codex together with a specific tools.bash allow-list (rather than bash: ["*"]). gh aw compile --strict correctly rejects this:
error: engine 'codex' does not support bash command allow-listing: tools.bash with specific
commands is silently ignored at runtime for this engine. Use 'bash: ["*"]' to allow all
commands or remove the tools.bash entry. To restrict bash commands, switch to an engine
that supports this feature (copilot, claude, or gemini)
gh aw fix --write reports "No fixes needed" and leaves the workflow broken — the compiler catches this only in --strict mode with no automated remediation path.
Evidence (2 repos)
OtterMind/Chat2DB
.github/workflows/ai-issue-assistant.md and .github/workflows/ai-pr-reviewer.md:
engine:
id: codex
version: "0.144.6"
tools:
bash:
- "gh *"
pockebot/openpocket
.github/workflows/issue-fix.md and .github/workflows/issue-plan.md:
tools:
bash: ["make", "git:*"]
(with engine.id: codex set elsewhere in the same file)
Proposed codemod
Add a codemod (candidate id: codex-bash-allowlist-to-wildcard) that, when engine.id is codex and tools.bash is a specific string list (not ["*"]):
- At minimum, make
gh aw fix (non-strict) surface this as a fixable diagnostic — today only gh aw compile --strict reports it, and fix silently does nothing.
- Optionally offer a
--write transform that rewrites the list to bash: ["*"] with an inserted comment explaining that codex ignores command-level allow-listing and that restricting bash requires switching engines (copilot, claude, or gemini).
Because rewriting to bash: ["*"] widens effective permissions (the allow-list was already a no-op for codex, but making that explicit is a semantic change worth calling out), this probably shouldn't apply silently by default — an explicit flag or a loud warning in the diff/preview seems appropriate.
Suggested fix for affected repos in the meantime
Switch engine.id away from codex to copilot, claude, or gemini if bash command restriction is required, or replace the allow-list with bash: ["*"] if unrestricted bash access under codex's own sandboxing is acceptable.
Generated by 🔧 Daily AW Cross-Repo Compile Check · agent · 314.4 AIC · ⊞ 7K · ◷
Summary
During the daily 20-repo compatibility audit, two independent public repositories hit the same unresolved compile-time incompatibility, and
gh aw fix --writedoes not offer a codemod to address it.Pattern
Workflows set
engine.id: codextogether with a specifictools.bashallow-list (rather thanbash: ["*"]).gh aw compile --strictcorrectly rejects this:gh aw fix --writereports "No fixes needed" and leaves the workflow broken — the compiler catches this only in--strictmode with no automated remediation path.Evidence (2 repos)
OtterMind/Chat2DB
.github/workflows/ai-issue-assistant.mdand.github/workflows/ai-pr-reviewer.md:pockebot/openpocket
.github/workflows/issue-fix.mdand.github/workflows/issue-plan.md:(with
engine.id: codexset elsewhere in the same file)Proposed codemod
Add a codemod (candidate id:
codex-bash-allowlist-to-wildcard) that, whenengine.idiscodexandtools.bashis a specific string list (not["*"]):gh aw fix(non-strict) surface this as a fixable diagnostic — today onlygh aw compile --strictreports it, andfixsilently does nothing.--writetransform that rewrites the list tobash: ["*"]with an inserted comment explaining that codex ignores command-level allow-listing and that restricting bash requires switching engines (copilot,claude, orgemini).Because rewriting to
bash: ["*"]widens effective permissions (the allow-list was already a no-op for codex, but making that explicit is a semantic change worth calling out), this probably shouldn't apply silently by default — an explicit flag or a loud warning in the diff/preview seems appropriate.Suggested fix for affected repos in the meantime
Switch
engine.idaway fromcodextocopilot,claude, orgeminiif bash command restriction is required, or replace the allow-list withbash: ["*"]if unrestricted bash access under codex's own sandboxing is acceptable.