Blog

Agent of the Day – September 1, 2026

Sep 1, 2026

Open pull requests have a way of quietly stalling — a CI check goes red and nobody notices, a review comment sits unanswered for a day, a branch drifts out of date. Today’s spotlight, PR Sous Chef, exists to catch exactly that kind of drift on gh-aw itself, checking in on every open, non-draft PR every fifteen minutes and nudging the Copilot coding agent only when there’s real work to hand back.

Agent of the Day: PR Sous Chef

PR Sous Chef runs on the pi engine with openai/gpt-5.4, triggered on a tight every 15m schedule plus an on-demand /souschef slash command for anyone who wants to pull it into a specific PR conversation. It fetches all open PR branches (refs/pulls/open/*), reads through PR state, checks, and comments, and decides whether a targeted nudge is warranted — then posts a Copilot request if so.

Recent runs on September 1 show the pattern clearly: five runs in a single afternoon, all completed successfully, ranging from quiet passes with a single safe item to busier sweeps producing eight or nine actions each — see run #33509763563 and run #33516358980. Across its last five runs combined, it generated 20 safe-output items with zero errors and zero warnings — a workflow that does its job and gets out of the way.

The audit trail on that latest run is worth a closer look: 13 out of 13 automated quality graders passed clean, covering everything from tool-success-rate (100%) to loop detection (zero) to context-growth efficiency. The one flagged item was a handful of blocked outbound requests to github.com:443 — five out of fifty-three total network calls — a firewall-policy nuance rather than a functional problem, since the run still completed successfully and produced its full set of nudges.

What makes PR Sous Chef worth watching is its restraint. It doesn’t comment on every PR every cycle; a 15-minute schedule paired with a handful of safe items per run means most cycles are pure read-only reconnaissance — checking state, finding nothing actionable, and moving on. Only when a PR has genuinely gone quiet does it step in with a Copilot request, keeping the review queue moving without adding comment noise to PRs that are already progressing fine on their own.

It’s a small, unglamorous job — but in a repo with dozens of PRs in flight at any given time, having something check in every quarter-hour so nothing falls through the cracks is exactly the kind of quiet infrastructure that keeps a fast-moving project from stalling.

Curious how workflows like PR Sous Chef are built? Explore the project at github.com/github/gh-aw.

Sandbox Security Options Are Now Runtime Profiles

Sep 1, 2026

Copilot

Peli de Halleux

Sandbox security behavior is now selected through sandbox.agent.runtime. The separate sandbox.agent.legacy-security and sandbox.agent.sudo settings have been removed, making each runtime an explicit security and topology profile.

The default docker profile runs AWF without sudo and isolates network access. Workflows that need the previous privileged iptables behavior can select docker-sudo-iptables:

sandbox:
  agent:
    runtime: docker-sudo-iptables

This profile runs AWF with sudo, uses iptables-based networking, and permits host and GitHub Actions service access. It is required for sandbox.agent.allow-host-ports and for connecting to published services: ports. Other profiles retain their own isolation guarantees: gvisor adds kernel-level isolation, while docker-sbx and cloud-hypervisor use virtual-machine boundaries.

Migrate existing workflows

Run the fixer to update workflow frontmatter:

gh aw fix --write

The sandbox-runtime-profiles codemod rewrites this configuration:

sandbox:
  agent:
    legacy-security: enable

to:

sandbox:
  agent:
    runtime: docker-sudo-iptables

The codemod also removes obsolete sudo settings and preserves compatible runtime choices. When a combination cannot be migrated without changing its security intent, the fixer reports an actionable error instead of selecting a profile silently.

After migration, compile the workflow and review the generated lock file:

gh aw compile

See the sandbox configuration reference and agent runtime reference for the behavior and constraints of each profile.

Why the Built-In Playwright Tool Is Now CLI-Only

Sep 1, 2026

Copilot

Peli de Halleux

The built-in tools.playwright integration in gh-aw used to support two modes: a Docker-based MCP server (mode: mcp) and a CLI-based integration (mode: cli). As of this change, the built-in tool only supports CLI mode, and the compiler rejects mode: mcp with migration guidance instead of quietly starting a container. Workflows that still need the full Playwright MCP server can configure it explicitly under mcp-servers. Here is why CLI became the only built-in option.

Fewer tokens spent on tool schemas

MCP servers advertise their tools to the agent by loading a schema for every available function into the model’s context window. Playwright MCP exposes a wide surface of browser-automation tools — navigation, snapshots, clicks, evaluation, tracing, and more — and all of that schema has to be paid for in tokens on every turn, whether or not the agent uses most of it.

@playwright/cli instead exposes a single command, playwright-cli, that the agent invokes directly from bash with a subcommand such as goto, snapshot, or click. The agent only needs to have seen playwright-cli --help once (or installed skills via playwright-cli install --skills) to know how to drive the browser. There is no persistent tool schema competing with the rest of the workflow’s context for space, which matters for coding agents that also need room to reason about code, tests, and long-running tasks.

A smaller, more auditable attack surface

The built-in MCP mode ran Playwright inside a Docker container with its own image, arguments, and lifecycle that the compiler had to track, pin, and update independently. Every one of those knobs — container image version, extra MCP arguments, mounted volumes — was one more thing that could silently drift out of date or be misconfigured across workflows.

CLI mode collapses that surface. @playwright/cli is a single npm package installed directly on the runner, with one version to track and one command surface to allow through the shell permission system. Because it runs on the runner instead of in a separate container, it also reaches local development servers through localhost directly, without needing extra network plumbing between a container and the host. Less machinery means less to get wrong, and less to review when auditing what a workflow can do.

MCP is still available, just not built-in

Some workflows genuinely benefit from MCP’s persistent state and richer introspection — for example, exploratory automation or self-healing tests that need to reason iteratively over page structure across many turns. That use case has not gone away; it is just no longer a hidden default. Configure it explicitly:

mcp-servers:
  playwright:
    command: npx
    args:
      - --yes
      - "@playwright/mcp@0.0.79"
      - --no-sandbox
    allowed:
      - browser_navigate
      - browser_snapshot

Making this explicit means the dependency, the pinned version, and the exact allowed tool list are all visible in the workflow source, instead of being implied by a one-word mode: mcp setting. See the Playwright reference for the full migration table from MCP tool names to playwright-cli subcommands.

Agent of the Day – August 31, 2026

Aug 31, 2026

Copilot

Every open-source repo eventually drowns in the same problem: a hundred open issues, half of them clearly related, none of them linked. Someone has to notice that six issues are all milestones of the same game plan, or that a dozen bug reports trace back to one root cause — and then actually go build the sub-issue tree. Today’s spotlight, Issue Arborist, is the daily workflow that does exactly that for gh-aw itself.

Agent of the Day: Issue Arborist

Every morning, Issue Arborist pulls the last 100 open issues that don’t already have a parent, reads through their titles, bodies, and labels, and decides what — if anything — deserves to be grouped. It’s deliberately conservative: it only proposes a brand-new parent issue when a cluster is strong and orphaned, and it only links a sub-issue when the relationship is unambiguous.

In its August 29 run, that discipline produced a genuinely useful cleanup. The agent noticed seven Deep Report issues — schema drift fixes, duplicate type consolidation, messaging tweaks — that were all clearly part of the same maintenance effort but had no tracking issue. Rather than link them to something that didn’t fit, it created a new parent, [Parent] Deep Report cleanup and schema consolidation, and attached all seven (#56706–#56712) underneath it. It then found two more clean clusters: four cache-miss issues that belonged under the existing Daily Cache Strategy Analyzer issue group (#56716), and six milestone issues for a fictional game project, “Neon Heist” (#56635), each one an obvious child of its own plan.

The very next day, on August 30, and again on August 31, it kept going — linking six more milestone issues for a different project, “Starling Drift” (#57144), and folding eight fresh [deep-report] findings into the existing issue-group parent (#56849), all without creating a single unnecessary new tracking issue.

What’s most interesting is what the agent chose not to do. Each run ends with a same-day discussion post explicitly listing the clusters it saw but declined to link — a group of near-duplicate “Implement skill-constraint-coverage” issues that might be duplicate attempts rather than a hierarchy, a set of repeated workflow-failure reports that could be separate incidents rather than one root cause, and several [aw] Smoke ... failed issues that looked plausible but weren’t confident enough to map automatically. That restraint is the whole point: a triage bot that links everything it can find isn’t useful, it’s noise. Issue Arborist’s value is in knowing when not to act.

Across its last three runs it made 129 link_sub_issue calls and opened one new parent issue — a quiet, steady gardening job that keeps gh-aw’s issue tracker legible without anyone having to ask it to.

Curious how workflows like Issue Arborist are built? Explore the project at github.com/github/gh-aw.

Weekly Update – August 31, 2026

Aug 31, 2026

Copilot

Another packed week for github/gh-aw! We shipped three pre-releases (v0.87.5, v0.87.8, and v0.87.9) and merged well over a hundred pull requests spanning new workflow scheduling controls, compiler hardening, and a steady stream of trajectory grader implementations. Here’s what stood out.

Release Highlights

The v0.87.9 line of pre-releases built on v0.87.8 and v0.87.5, focused on new workflow gating primitives, engine reliability, and internal grader tooling.

on.cooldown workflow gating (#56998): workflows can now declare a cooldown window so back-to-back triggers don’t pile up on the same target.
Typed on.stop-after field (#56983): stop-after now accepts GitHub Actions expressions in addition to static values, giving authors more flexible run-limiting logic.
Codex harness tool-schema diagnostics (#57256): unsupported-model tool-schema failures now surface with a dedicated, readable error message instead of a cryptic provider error.
Bump default MCP Gateway to v0.4.14 (#57188) and Bump Agentic Workflow Firewall to v0.28.10 (#56914): the usual steady drumbeat of dependency upgrades keeping the sandboxing and networking layers current.

Notable Pull Requests

Document intent-driven workflow design: new guidance explains how to write workflow prompts around clear intent rather than rigid step-by-step instructions, complementing the earlier intent-driven workflow design guidance and the optional intent frontmatter field (#56599).
Add the Feature Farmer workflow pattern: a new documented pattern for workflows that continuously grow small, incremental features — later put into practice by converting the trajectory grader workflow to the “all-you-can-eat” pattern.
Prevent large MCP query payloads from exceeding argument limits: a reliability fix so oversized MCP requests fail gracefully instead of silently breaking tool calls.
Support authenticated Agent Plugin installation from private repositories: opens up plugin installation for teams running private forks or internal plugin repos.
Add Bash support for Windows runners: another step toward first-class Windows runner support for agentic workflows.

Under the hood, the team also kept implementing new entries in the trajectory grader library — including event-entropy-rate, lempel-ziv-trajectory-complexity, policy-near-miss, exploration-error, and exploitation-error — building out a richer picture of how agents behave across runs.

Agent of the Week: AI Moderator

AI Moderator is the quiet gatekeeper that watches newly opened issues, comments, and pull requests for spam, AI-generated noise, and link spam, then quietly labels or hides what it finds.

This week it stayed busy on the front lines — triggered repeatedly across incoming issues and PRs, including runs tied to the Codex harness fix (#57256) and a caveman instruction-verbosity pass. It runs read-only by design (no write-capable safe outputs get exercised unless it actually flags something), which is exactly the kind of low-risk, always-on moderation you want watching your front door.

Its recent runs did turn up as reliability “failures” in our observability logs — a reminder that even the calmest bouncer occasionally needs a coffee break, or in this case, a closer look at run classification before we assume the worst.

Usage tip: Because it runs read-only with threat-detection: false and tight per-window rate limits, ai-moderator is a solid template for any workflow that needs to watch high-volume public triggers (like issues: opened or pull_request: opened from forks) without risking runaway write actions.

→ View the workflow on GitHub

Try It Out

Update to v0.87.9 and give on.cooldown or the new intent-driven design guidance a try. As always, feedback and contributions are welcome in github/gh-aw.