GitHub Agentic Workflows 0.87.9 Adds Cooldowns and Dynamic Stop Conditions to Strengthen Agent Execution Boundaries

GitHub Agentic Workflows (`gh-aw`) has successively released preview versions 0.87.5, 0.87.8, and 0.87.9, further moving controls over agent automation trigger frequency, stop timing, and access scope into compilable workflow configuration. The new `on.cooldown` can define a cooldown window for the same target, reducing execution backlogs caused by frequent issue, PR, or scheduled triggers. In addition to static values, the typed `on.stop-after` can use a GitHub Actions expression to calculate execution deadlines based on events, inputs, or upstream job results.

These updates also improve error diagnostics in the Codex harness: when a model does not support a specified tool schema, the system now provides a dedicated message instead of merely relaying a vague provider error. Version 0.87.9 also expands Windows runner support for Bash and PowerShell, allows Agent Plugins to be installed from private repositories, and makes the MultiRepoOps sidecar check out only target repositories, reducing unnecessary cloning overhead.

Permission and output boundaries have also been adjusted. The enclave can now receive read-only access to GitHub Issues, the set of network domains used by the execution engine is now explicitly opt-in, and safe-output JSON has been fixed to prevent GitHub Actions operators from being corrupted. These designs place more direct compiler- and permission-layer constraints on when an agent starts, when it stops, and what it can read. However, the `intent` field, which lets authors describe a workflow’s purpose, is not a permission policy. Private plugins also broaden the scope of credential management, source pinning, and software supply chain audits.

This release continues the version evolution following reporting on PR steering in 0.87.4. An earlier official weekly update attributed the steering feature—which had not yet landed in a pinned release—to v0.87.4, creating a mismatch between the update’s claims and the tag’s actual contents. Because the project pins both the CLI and compiled workflow versions, teams should not determine feature availability from weekly updates or version numbers alone. After upgrading, they must still verify the actual tag or commit, recompile, and review the committed `.lock.yml` to confirm that the new settings, permissions, and plugin sources are properly pinned.