GitHub Agentic Workflows | Blog

Agent of the Day – September 10, 2026

Thu, 10 Sep 2026 00:00:00 GMT

Documentation drift is the quiet failure mode of every fast-moving codebase. A function gets added, a README doesn’t get updated, and six months later someone new to the repo is reading stale prose next to code that no longer matches it. Today’s Agent of the Day exists to catch that drift before it becomes a habit — not with a vague “keep docs current” nag, but with an actual scored audit.

Agent of the Day: Package Specification Librarian

The Package Specification Librarian runs every day against gh-aw itself, reading every README.md under pkg/ and comparing it against the real exported symbols in the corresponding Go source. It’s not looking for typos or style nits — it’s checking whether the documentation still tells the truth about the code.

Its most recent run, #34481937715 on September 10, took 16.6 minutes and completed cleanly with no errors, then opened issue #59985: “Specification Audit — 2026-09-10 — 5 issues found.” The report is refreshingly precise about scope. Out of 37 packages, 36 have specs — a 97% coverage rate — and the one true gap, pkg/workflowcontract, isn’t even a missing-doc problem so much as a package that exists purely to hold a contract-test guard and never got a README explaining why.

The rest of the findings show real discipline in separating signal from noise. The agent flagged pkg/cli and pkg/workflow for a dozen undocumented exported functions each — including cobra command constructors like NewEditCommand and NewGradersCommand that back user-facing gh aw subcommands but never made it into the README’s command table. It also caught two small real gaps: ResolveGHESActionPin missing from pkg/actionpins, and IsNotFoundOutput missing from pkg/errorutil. Then, notably, it double-checked five other flagged packages (setutil, styles, types, among others) and correctly ruled them false positives — generic type-parameter tokens like comparable] tripping up the naive scan, or methods already documented under a different heading. That verification step is the difference between a useful audit and a noisy one.

Each finding comes with a quality score across four dimensions — completeness, accuracy, consistency, freshness — so maintainers get a number to track, not just a wall of text. The issue closes with a concrete action-item checklist and a note to include Closes #59985 in any fix PR, linking the paper trail all the way through. Looking back at prior runs — #58993 on September 6 found 3 issues, #57954 on September 2 found 6 — the pattern holds: five consecutive successful runs, zero errors, and a steadily shrinking backlog of undocumented symbols as the fixes land.

It’s a small, unglamorous job done consistently — which is exactly what documentation maintenance needs to actually work.

Try It Yourself

Curious how a daily audit agent like this fits into your own repository? Explore the gh-aw project on GitHub and see how agentic workflows can keep your codebase honest, one scheduled run at a time.

Agent of the Day – September 9, 2026

Wed, 09 Sep 2026 00:00:00 GMT

Coverage reports are easy to generate and easy to ignore. Somewhere in every large Go codebase there’s a pile of small, deterministic functions — string parsers, formatters, pure transforms — that nobody ever got around to testing, because writing the test felt like more effort than the function was worth. Today’s Agent of the Day exists specifically to burn through that pile, three functions at a time, every single day.

Agent of the Day: PureLock

PureLock runs on a daily schedule against gh-aw itself, and its design is unusually disciplined about not wasting effort. A precompute job does all the expensive, deterministic legwork up front: it merges coverage profiles, type-checks ./pkg/... with go/packages, runs a fixed-point side-effect analysis to confirm a function has no observable side effects, and ranks the resulting pure-function candidates by how weak their coverage is. By the time the AI agent wakes up, it isn’t exploring the repository — it’s handed a ranked, verified list and told to spend its budget writing tests, not searching for work.

The orchestrator then picks up to three candidates that haven’t been touched in the last 60 days (tracked via a cache-memory state file), and fans out to parallel test-writer sub-agents — one per function, all launched simultaneously rather than sequentially. Each sub-agent independently verifies purity, writes a table-driven test file, and reports back coverage deltas before anything gets merged into a single draft PR.

The evidence from real runs backs this up. In PR #56895, merged on August 29, PureLock locked down three functions in one pass: selectHistoricalOperationalValueGrader went from 0% to 100% function coverage with a 10-subtest table, extractHostFromRemoteURL climbed from 64% to 96% by adding four new cases for URL-parsing fallback branches, and extractOTLPAttributesFromObsMap hit 100% with nine subtests covering nil maps, type mismatches, and silent-drop behavior for non-string values. Every claim is backed by a gofmt, go vet, and go test -race pass recorded directly in the PR body — no unverified assertions, no rubber-stamped merges.

Recent scheduled runs (agenticworkflows logs, last five for purelock) show the pattern holding steady: three consecutive successes on September 6–8, each completing in roughly 13–14 minutes and consuming around 25–26K peak input tokens per run, well within its max-daily-ai-credits budget. Earlier PRs — like #54539 locking down two discussion-trigger and git-ref helpers, and #54235 covering three parsing/cache-naming functions — show the same steady rhythm going back to the workflow’s original bootstrap in #51107. A dedicated fix, PR #57948, even shipped to resolve a Go cache-restore collision the workflow had triggered against itself — proof the project treats PureLock’s infrastructure with the same rigor as any other production agent.

What makes PureLock a good Agent of the Day pick isn’t just that it writes tests — it’s how conservatively it does it. Every result gets re-validated (gofmt, go vet, go test -race) before it’s allowed anywhere near a PR, failed candidates get logged as noop and skipped rather than forced, and every run — success or failure — updates a durable cache so the same function is never redundantly re-analyzed. It’s a small, patient agent doing unglamorous work, and the coverage numbers in pkg/cli and pkg/parser are quietly better for it.

Want to see how PureLock (or any other agentic workflow) is built? Explore the project and start your own agent at github.com/github/gh-aw.

Agent of the Day – September 8, 2026

Tue, 08 Sep 2026 00:00:00 GMT

Every toolchain rots a little every day. Dependencies drift, CLIs ship silent patches, base images get new digests — and nobody notices until something breaks in CI at the worst possible moment. Today’s Agent of the Day exists specifically to make sure that never happens quietly: the CLI Version Checker.

Agent of the Day: CLI Version Checker

This workflow runs on a daily schedule and has one job: watch eight different tools — Claude Code, GitHub Copilot CLI, OpenAI Codex, GitHub MCP Server, Playwright CLI, MCP Gateway, Pi, and threat-detect — plus a stack of Docker images (actionlint, syft, grype, grant, zizmor, poutine, runner-guard, yamllint) for version or digest changes. When it finds one, it opens a pull request. When it doesn’t, it says nothing and exits — no busywork issues, no noise.

Looking at the last five scheduled runs, the pattern is exactly what you’d want from an agent like this:

Run #552 (Sep 8) — completed in 7.6 minutes, checked every tracked package via npm view and the GitHub Releases API, found nothing new to update, and exited cleanly.
Run from Sep 7 and Sep 6 — same story: full version sweep, no drift detected, quiet success.
Two earlier runs on Sep 4–5 failed outright, a useful reminder that even a narrowly-scoped, read-mostly agent needs monitoring too.

What makes this workflow interesting isn’t the happy path — it’s the discipline baked into the process. The agent is instructed to check a local cache before doing any network calls, to prefer npm view over web-fetch for package metadata (cheaper and faster), and to fetch every tool’s version in parallel rather than serially grinding through eight lookups one at a time. When it does detect a real change, it doesn’t just bump a constant — it pulls GitHub release notes, converts every #1234 PR reference into a full external URL, categorizes changes as Breaking/Features/Fixes/Security/Performance, and only then runs make recompile before opening the PR.

The audit trail also surfaced something small but real: every recent run hit a firewalled domain, ab.chatgpt.com:443, and got blocked — 1 request out of roughly 50 per run. Harmless in this case (the agent’s actual work sails through on api.openai.com), but it’s exactly the kind of “friction” signal that gh aw’s built-in auditing is designed to surface so maintainers can decide whether to allow-list it or leave the firewall as-is.

There’s a quieter lesson here too: not every agent needs to be flashy to be valuable. CLI Version Checker doesn’t triage issues or refactor code — it just refuses to let toolchain drift become tomorrow’s fire drill. That’s the kind of agent you forget exists, right up until the day it saves you from shipping against a version nobody remembered to check.

Curious how a workflow like this is put together, or want to build your own quietly-vigilant agent? Check out github/gh-aw.

Agent of the Day – September 7, 2026

Mon, 07 Sep 2026 00:00:00 GMT

Every codebase accumulates functions nobody calls anymore — refactors that leave a helper behind, a compatibility shim that outlived its purpose, a test double for logic that got deleted three PRs ago. Most teams let it pile up until someone dedicates a “cleanup sprint” to it. gh-aw just runs an agent every day instead.

Agent of the Day: Dead Code Removal Agent

Today’s spotlight goes to Dead Code Removal Agent, a scheduled workflow that runs Go’s deadcode static analyzer against ./cmd/... and ./internal/tools/..., then opens a pull request removing whatever it finds unreachable — along with any tests that existed solely to exercise that dead code.

Its recent run history tells an honest story, not a highlight reel. Looking at the last five scheduled runs via agenticworkflows logs, three failed with agent-logic errors and two succeeded cleanly. That’s the nature of static-analysis-driven automation: some days the analyzer’s findings are messy enough that the agent bails rather than risk a bad deletion. The two clean runs, though, show exactly what this workflow is built for.

The most recent success, run #204 on September 6, took 19 minutes and 19,398 tokens to produce PR #58996: “[dead-code] chore: remove dead functions — 5 functions removed.” The diff is small and surgical — 10 additions, 34 deletions, 4 files touched. It removed four unreachable functions from pkg/cli/add_workflow_compilation.go (compileWorkflowWithRefresh, compileWorkflowWithTracking, compileDispatchWorkflowDependencies, compileCallWorkflowDependencies) plus RunShellcheckOnLockFiles from pkg/cli/compile_external_tools.go. Five matching tests went with them, since a test for code that no longer exists is itself dead weight.

The PR body reads like a self-contained audit trail: it lists the exact functions and files removed, the tests removed, and a verification checklist (go build ./..., go vet ./..., go vet -tags=integration ./... all checked; make fmt flagged one pre-existing, unrelated fmt-json failure rather than papering over it). That kind of transparency is what makes an autonomous cleanup agent trustworthy enough to merge without a human re-deriving its logic from scratch.

What’s especially fun is watching gh-aw’s agents cross paths. The same PR got a follow-up pass from PR Sous Chef, another daily workflow that nudges stale pull requests — its comment on #58996 is baked right into the PR history, a small reminder that these agents aren’t operating in isolation; they’re part of an ecosystem that reviews, nudges, and merges each other’s work. Maintainer @pelikhan merged the PR a couple hours after it opened.

Zoom out across the workflow’s history and the pattern holds: PR #58822, #55418, and #54835 are all the same shape — five, five, and one functions removed respectively, each with its matching tests, each merged. It’s not flashy work, but it’s the kind of relentless, low-noise maintenance that keeps a fast-moving Go codebase from quietly bloating with orphaned code between real refactors.

Not every run is a success, and that’s fine. An agent that occasionally declines to act, rather than force a risky deletion, is doing exactly what you’d want a cleanup crew to do — take the clean wins, skip the ambiguous ones, and leave a paper trail either way.

Want to see how a daily static-analysis agent turns deadcode output into a real pull request? Explore the workflow definitions and start building your own at github.com/github/gh-aw.

Weekly Update – September 7, 2026

Mon, 07 Sep 2026 00:00:00 GMT

Another busy week for github/gh-aw! The team shipped a new release focused on hardening the agentic firewall and CI reliability, while dozens of pull requests tightened up sandboxing, model configuration, and safe-output handling across the fleet of agentic workflows.

Release: v0.88.4

v0.88.4 landed this week, focused on hardening the agentic firewall/network layer, improving CI reliability, and expanding project tooling support.

What’s New

Trusted enclave sensitivity support (#58328): adds finer-grained sensitivity controls for trusted enclave workflows.
DIFC policy generation for GitHub App workflows (#58302): automatically generates data-flow integrity/confidentiality policies for workflows authenticated via a GitHub App.
aw.json project support in the add command (#58267): makes it easier to add workflows into existing aw.json-based projects.
Daily Linear and Jira smoke issues workflow (#58320): adds scheduled smoke-testing coverage for Linear and Jira integrations.

Bug Fixes & Improvements

Fixed root-relative workflow paths in imported local manifests (#58317).
Fixed Pi Anthropic routing through the firewall (#58313).
Disabled OTLP export when authorization secrets are empty, avoiding noisy failed exports (#58312).
Preserved setup-ruby PATH precedence inside the Agentic Workflow Firewall (#58311).

Notable Pull Requests

Beyond the release, the past week’s merge queue was dominated by fleet-wide reliability work:

Migrate agentic workflows to Cloud Hypervisor: a major infrastructure shift moving the workflow fleet onto Cloud Hypervisor-based microVMs for better isolation.
Wire dynamic enclave delegation controller into the workflow runtime: lays groundwork for more flexible trusted-enclave delegation.
Add compiler support for dynamic repository enclave policies: lets repository-level policies drive enclave behavior dynamically.
Reclassify policy-driven safe-output declines as skipped, not hard failures: makes workflow runs easier to triage when a safe output is intentionally blocked by policy rather than broken.
Several workflows got model-configuration fixes to stay on Codex-compatible models, including the Daily Go Test Parallelizer, Auto-Triage Issues, and Linter Miner — a good reminder to keep an eye on model deprecations across your own workflow fleet.

Agent of the Week: dead-code-remover

The tidiest member of the team — it scans the Go codebase for unreachable functions using static analysis and opens a PR to remove a small batch every day.

This week dead-code-remover ran three times and kept up its steady rhythm: two clean runs each produced a PR titled “[dead-code] chore: remove dead functions — 5 functions removed” (#58996, #58822), quietly trimming five functions each time, while one run hit a snag and came back empty-handed rather than force through a bad batch.

It never removes more than five functions per run — a self-imposed diet that keeps every PR small enough for a human to review in a coffee break, and disciplined enough that nobody’s ever caught it trying to sneak in a sixth.

Usage tip: Cap batch size like this for any “cleanup” agent — small, reviewable PRs land far more often than one giant sweep.

→ View the workflow on GitHub

Try It Out

Update to v0.88.4 and check out the new trusted enclave and DIFC policy features. As always, feedback and contributions are welcome in github/gh-aw.

MicroVM Support Is Consolidating on Cloud Hypervisor

Sat, 05 Sep 2026 00:00:00 GMT

GitHub Agentic Workflows is consolidating its specialized sandbox runtime support on cloud-hypervisor. The gvisor and docker-sbx runtime options are deprecated and will be removed in a future release.

docker-sbx introduced a KVM-backed microVM boundary, while gvisor provided a user-space kernel between the agent container and host kernel. Maintaining both paths alongside Cloud Hypervisor created separate installation, compatibility, and troubleshooting surfaces. Consolidating on one microVM implementation makes the stronger isolation path more consistent and easier to evolve.

What changes

The default docker runtime remains available and continues to run AWF with network isolation and proxy enforcement. For workflows that require a hardware-virtualized boundary, cloud-hypervisor is now the supported direction:

---
on: issues
sandbox:
  agent:
    runtime: cloud-hypervisor
---

Investigate this issue.

Cloud Hypervisor support is currently in preview and requires a GitHub-hosted Ubuntu x86_64 runner with /dev/kvm. The compiler adds the required host checks and provisions digest-pinned runtime assets.

Migrating existing workflows

Review workflows that explicitly set runtime: gvisor or runtime: docker-sbx. Select cloud-hypervisor when the workflow runs on an eligible GitHub-hosted runner and needs a microVM boundary. Otherwise, remove the runtime setting to use the default Docker profile.

Compile each updated workflow and review the generated lock file:

gh aw compile

The deprecated values remain documented during the transition, but new workflows should use either the default Docker runtime or cloud-hypervisor. See Agent Runtime Selection for requirements and tradeoffs.

Agent of the Day – September 3, 2026

Thu, 03 Sep 2026 00:00:00 GMT

Some workflows in gh-aw wait for a slash command or a pull request event before they lift a finger. Today’s spotlight has no patience for that. Every 40 minutes or so, it wakes up on its own schedule, scans the open issue tracker, picks out the most promising candidates, and hands them straight to the Copilot coding agent. Its name is exactly as subtle as its appetite: Issue Monster.

Agent of the Day: Issue Monster

Issue Monster is a scheduled gh-aw workflow (.github/workflows/issue-monster.md) whose entire job is triage-by-appetite. It has a pre-fetched view of the open issue queue, a short list of skills — issue-monster-report-formatting and issue-monster-token-budget — to keep its output tight and cheap, and exactly three safe-output moves per run: assign_to_agent, add_comment, and noop if nothing qualifies.

Watching a stretch of its actual runs from earlier today tells the story better than any spec could. Between run #33740299445 and run #33766461931 — ten consecutive runs spanning about four hours — Issue Monster completed successfully every single time, burning roughly 1 million tokens and 103 action-minutes total, with zero errors, zero warnings, and zero missing tools across the board.

What makes the run interesting isn’t the token count, it’s the reasoning trail. In its most recent run, the agent’s internal notes show it weighing overlapping candidates before committing:

“I see some top candidates like #57408 (domains audit), #57728 (stale code-scanning alert), #57709 (CLI consistency)… I must ensure these issues are distinct and not overlapping… I’ll aim for the highest-scored independent issues.”

It settled on three genuinely separate issues — a security-hardening fix, a documentation gap, and a refactor — and for each one called assign_to_agent followed immediately by a comment announcing the decision:

Issue Monster selected this for Copilot — I’ve identified this issue as a good candidate for automated resolution and requested assignment to the Copilot coding agent. Om nom nom!

The cookie-monster signature isn’t just flavor text; it’s a consistent, greppable marker across issue #57408 (default domain allowlist hardening), issue #57709 (CLI docs consistency), and issue #58148 (workflow-skill extraction refactor) — three issues that, as of this run, are now sitting in the Copilot coding agent’s queue waiting for a PR.

Earlier runs in the same window picked up other issues from the same rotating shortlist, including #57142 (a Go package refactor) and #58240 (a large parser file split), showing the agent isn’t just repeating the same three picks — it re-evaluates the queue and reprioritizes as issues get claimed or closed.

The gh-aw audit tooling flagged one low-severity note worth mentioning: Issue Monster’s task profile (narrow tool breadth, read-mostly posture, moderate resource use) is a candidate for a cheaper model like gpt-4.1-mini instead of a frontier engine — a reminder that even a workflow running dozens of times a day has room to trim its own cost curve. That’s the kind of self-aware feedback loop gh-aw’s observability tooling is built to surface automatically, run after run.

No fanfare, no dashboard to babysit — just a small, disciplined loop that turns “here’s an open issue” into “here’s an assigned Copilot task” every 40 minutes, day and night.

Want to build something with the same rhythm? Explore the workflows, skills, and safe-output patterns behind Issue Monster at github.com/github/gh-aw.

Agent of the Day – September 2, 2026

Wed, 02 Sep 2026 00:00:00 GMT

Agent of the Day – September 2, 2026: The Complexity Cop

Most PR bots check style, tests, or security. Today’s spotlight, Ponytail Reviewer, checks something harder to quantify: whether a change is more complicated than it needs to be. It runs on every pull request marked ready for review in gh-aw (and on demand via a /ponytail slash command), applies the community-maintained ponytail-review skill, and only speaks up when it finds real over-engineering — no noise, no rubber-stamping.

What the logs actually show

Pulling the last three runs from agentic-workflows logs and audits paints a workflow that’s doing its job quietly and reliably:

Run #33596102316 — a 7-minute pass over PR #57860 (branch copilot/sergo-fix-linters-silent-delete), completed successfully with the Codex engine, burning 164K tokens across 8 model requests.
Run #33637292011 — another clean 7-minute review, this time against a copilot/task-9919-* branch, also completing without incident.
Run #33635177913 — a quick 7-second run against a PR titled “Fix daily-token-consumption-report: replace unsupported claude-sonnet-4.5 model”, which failed fast rather than burning minutes on a doomed invocation — exactly the kind of fail-cheap behavior you want from an automated reviewer.

Across all three runs: zero errors, zero missing tools, and two safe-output items generated in total — meaning Ponytail Reviewer isn’t just running, it’s making judgment calls about when a comment is actually warranted versus when a PR is clean enough to leave alone.

Built for restraint, not volume

The workflow’s configuration reflects that philosophy directly. It caps itself at 10 review comments and exactly one submitted review per run, scoped to COMMENT-level feedback only — it can flag concerns but can’t block a merge outright. It also shares a pr-review-base import with min-integrity: approved, meaning it won’t act on unverified or low-trust pull request content, and it pre-fetches diff data through a shared caching layer so repeated invocations on the same PR don’t re-download the same context.

Running on codex with the copilot/mai-code-1-flash-picker model, it’s tuned to be fast and cheap per invocation (roughly 3–8 AIC per run in these samples) rather than exhaustive — a reviewer that shows up quickly, says its piece if there’s something to say, and gets out of the way.

Why this matters for `gh-aw`

Complexity creep is invisible day-to-day and expensive in aggregate. A reviewer whose entire mandate is “is this more complicated than it needs to be?” is a narrow lens, but it’s one humans rarely apply consistently under review-fatigue. Ponytail Reviewer applies it on every ready-for-review PR, for free, every time.

Try it yourself

Curious how it works under the hood? The workflow definition lives at .github/workflows/ponytail-reviewer.md in github/gh-aw. Explore the full catalog of agentic workflows, or build your own, at github.com/github/gh-aw.

Agent of the Day – September 1, 2026

Tue, 01 Sep 2026 00:00:00 GMT

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

Tue, 01 Sep 2026 00:00:00 GMT

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

Tue, 01 Sep 2026 00:00:00 GMT

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

Mon, 31 Aug 2026 00:00:00 GMT

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

Mon, 31 Aug 2026 00:00:00 GMT

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.

Agent of the Day – August 28, 2026

Fri, 28 Aug 2026 00:00:00 GMT

Most teams write lint rules once and trust them forever. Nobody goes back to ask whether the rule’s own error message is still telling the truth, or whether a fix applied to one rule ever made it to its dozen siblings. Today’s spotlight, ESLint Refiner, exists precisely for that blind spot: a daily workflow that treats gh-aw’s custom ESLint rule set — eslint-factory — as a codebase worth auditing in its own right, not just a tool you point at other code.

Agent of the Day: ESLint Refiner

eslint-factory is the internal library of custom lint rules that keep actions/setup/js scripts safe — things like “wrap this fs.mkdtempSync call in a try/catch” or “don’t compare objects with JSON.stringify equality.” Rules like these accumulate fast; a sibling workflow, eslint-miner, adds roughly one new rule a day. But nobody was reviewing whether the rules themselves stayed correct as the pile grew. ESLint Refiner picks two of the least-scrutinized rules each run, checks their logic against real call sites in the codebase, and only files an issue when it finds something grounded in an actual bug — not a hypothetical.

In its August 27 run, the agent reviewed require-mkdtempsync-try-catch and require-decodeuricomponent-try-catch, and turned up two real problems:

A recurring overclaim. Eleven rules — including both reviewed that day — say a call “will crash the action if unhandled.” That’s not quite true: every entrypoint in actions/setup/js already has a top-level try/catch that routes any uncaught throw into a controlled core.setFailed, so nothing actually crashes silently. The real cost of skipping the fix is losing a specific { cause } and message, not crashing. This exact wording had already been fixed once, for require-fetch-response-body-try-catch, but the fix never propagated — and had since recurred in two brand-new rules. The agent filed issue #56288 asking for a reword-all pass plus a guard so it can’t quietly recur a third time.
A misclassified literal. require-decodeuricomponent-try-catch only recognized string literals as provably safe arguments, so calls like decodeURIComponent(42) or decodeURIComponent(null) got flagged even though a number, boolean, or null can never produce a decoding error. Zero live call sites hit this today, but it’s a cheap, well-scoped fix worth closing before one does — filed as issue #56289.

Rather than silently move on, the agent also published a same-day discussion post summarizing exactly what it checked, what came back clean, and what’s queued for tomorrow’s review — including a note that its own repo-memory had gone stale for weeks even while it kept filing issues, which it then rebuilt from a ground-truth GitHub search.

The following day’s run, on August 28, kept the streak going with another clean pass — no errors, three safe outputs produced, business as usual for a workflow that’s quietly been doing this every day since it launched.

What makes ESLint Refiner worth spotlighting isn’t flashy output — it’s discipline. It doesn’t flag speculative issues; it grounds every finding in live call sites before filing, and it explicitly tracks precedent (citing the earlier fix for the same defect class) so fixes actually propagate instead of getting re-invented rule by rule.

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

Agent of the Day – August 26, 2026

Wed, 26 Aug 2026 00:00:00 GMT

Agent of the Day – August 26, 2026: The CLI Archivist

Every CLI accumulates small inconsistencies over time — a flag renamed here, a doc page that forgot to follow, an extra blank line nobody meant to leave in. Today’s spotlight workflow exists purely to hunt down that kind of drift before a human ever notices it: the CLI Consistency Checker.

Agent of the Day: CLI Consistency Checker

This is a patient, unglamorous job done exceptionally well. Each day the workflow collects the full --help output for every one of the gh aw CLI’s 40-plus top-level commands and subcommands, then lines it up against docs/src/content/docs/setup/cli.md looking for typos, flag-naming inconsistencies, missing --no-* negation counterparts, undocumented commands, and stale examples. It’s the kind of exhaustive line-by-line comparison a person would dread doing manually — which is exactly why it’s automated.

Two consecutive runs this week show the pattern at its best. On run 32924017960 (August 25), the checker filed issue #55788, flagging that the graders command — a fully functional first-class CLI command with its own operational-value subcommand — was completely absent from the documentation. That report was closed out same-day by PR #55794, which added the missing docs.

The next day’s run, 32974417489, turned up something subtler: issue #56047 reported that seven commands — including gh aw add, gh aw logs, gh aw trial, and three mcp subcommands — were rendering two blank lines before their Flags: section instead of the single blank line used everywhere else. The root cause traced back to trailing newlines left inside Go raw string literals for each command’s Example: field. Cosmetic, yes, but the kind of thing that makes a CLI feel polished versus slightly off. PR #56052 trimmed the stray newlines and merged the same day, restoring consistent formatting across all seven commands.

What stands out across both runs is the discipline of the reports themselves: a clear severity breakdown, an affected-commands table, a root-cause section pointing at the exact source file, and — critically — zero false positives. Neither run flagged noise; every finding led directly to a merged fix. That’s the bar an agent needs to clear to earn trust running unattended on a schedule.

It’s a quiet workflow — no flashy dashboards, no dramatic incident response — just a steady daily diff between what the CLI says it does and what the docs say it does. But drift like this compounds silently in any fast-moving codebase, and catching it same-day, every day, is exactly the kind of tedious vigilance agentic workflows are built for.

Curious how a workflow like this is defined? Check out github/gh-aw and see how a few lines of markdown frontmatter turn into a disciplined daily CLI audit.

Agent of the Day – August 25, 2026

Tue, 25 Aug 2026 00:00:00 GMT

Some workflows in gh-aw wait patiently for a human to summon them. Today’s spotlight isn’t one of those. It wakes up every 30 minutes, peers into the open issue tracker, picks out the tastiest morsel it can find, and hands it straight to the Copilot coding agent. Its name says it all: Issue Monster.

Agent of the Day: Issue Monster

Described in its own frontmatter as “the Cookie Monster of issues,” this workflow runs on a schedule: every 30m trigger with a set of guardrails that keep it from overreacting. It skips a run entirely if there are already five or more open draft PRs from app/copilot-swe-agent, skips if there are no open issues to consider, and skips if key CI checks (build, test, lint-go, lint-js) are failing. Before picking a new target, it even checks for recent rate-limiting signals on Copilot-authored PRs from the last hour, so it doesn’t pile more work onto an agent that’s already struggling.

Five real runs from the last day tell a consistent story of steady, careful triage:

Run 32853285457 (8.9 minutes, 3 turns) evaluated the tracker and moved on without a strong enough candidate that cycle.
Run 32856106356 found three good bites in one pass, assigning issue #55788, issue #55770, and issue #55716 to the Copilot coding agent, each with a HIGH-confidence rationale that they were “clearly scoped, independent candidates for automated resolution.” Every assignment came with a cheerful comment: ” Issue Monster selected this for Copilot… Om nom nom! ”
Run 32859101860 picked up the pace again shortly after, assigning issue #55771 and issue #55768.
Run 32821436131 and Run 32816269740 ran earlier in the day, each completing in 6–8 minutes with clean, error-free conclusions.

Across all five runs, the workflow burned through 350k tokens and racked up 125 GitHub API calls — mostly reads, scanning issue bodies, checking recent PR activity, and verifying rate-limit safety before ever touching the assign_to_agent safe output. Of the five runs, two executed write-capable safe outputs (the assignments and comments above) while three stayed strictly read-only, quietly confirming there was nothing worth biting into that cycle. Zero errors, zero warnings, across the board.

That restraint is the real design story here. Issue Monster only has issues: read and pull-requests: read permissions directly — it never edits code itself. Its entire job is curation: reading the room, checking capacity, and making a narrow, well-reasoned call about which issue is ready for an autonomous fix versus which one still needs a human’s judgment. The assign_to_agent safe output does the heavy lifting of actually routing the issue to Copilot, and the accompanying comment keeps the paper trail visible to anyone watching the issue.

It’s a small, unglamorous job — but multiplied across dozens of runs a day, it’s the difference between an issue tracker that silently accumulates backlog and one where fixable problems get routed to an agent within half an hour of becoming “clearly scoped.” Om nom nom, indeed.

Curious how Issue Monster — or any other gh-aw workflow — is put together? Explore the project at github.com/github/gh-aw.

Agent of the Day – August 24, 2026

Mon, 24 Aug 2026 00:00:00 GMT

Agent of the Day – August 24, 2026: The Workflow Doctor

Most agentic workflows in gh-aw run on a timer, quietly doing their thing every day whether anyone’s watching or not. Today’s spotlight is different: it only shows up when you call it. Type /q in a comment on an issue, pull request, or discussion, and this workflow wakes up, reads the room, and goes to work fixing whatever you pointed it at.

Agent of the Day: The Workflow Doctor

We’re calling this persona The Workflow Doctor, and it belongs to Q, a slash-command-triggered gh-aw workflow described in its own frontmatter as an “intelligent assistant that answers questions, analyzes repositories, and can create PRs for workflow optimizations.” Q runs on the Copilot engine with SDK mode enabled, has read access to issues, pull requests, and discussions, and — critically — is under a hard rule never to touch its own definition file (q.md). It exists purely to diagnose and improve other workflows in the repo.

Three real runs from the last few days show exactly how varied its case load gets:

Run 32726221560 fired from a comment on discussion #55296, where a maintainer asked Q to “add a job that tests the github MCP in remote mode without using any agentic workflow feature” as a canary test to rule out a runtime/compiler bug, plus a summary of the MCP handshake message. Q completed in 11.5 minutes across a single turn, burning 25.8k tokens, and wrapped up with a successful conclusion and a proposed pull request queued up.
Run 32727642327 answered a comment on issue #55389 asking Q to “use mai flash model to reduce cost” — a straightforward cost-tuning request that Q turned into a workflow-level model swap.
Run 32726004596 came from discussion #55334, where the ask was to “update to use repo-memory to store the mined loops” — plumbing persistent state into a workflow that was previously stateless between runs.

Audit data on the discussion-triggered run classifies its behavior fingerprint as directed execution with narrow tool breadth and a selective_write actuation style — in plain terms, Q doesn’t wander. It reads exactly what it needs (the triggering comment, the parent issue or discussion, recent logs and audits for the target workflow), forms a specific diagnosis, and proposes a scoped pull request through its create-pull-request safe output, complete with a [q] title prefix, automation and workflow-optimization labels, and Copilot as the default reviewer.

That safe-outputs configuration is worth calling out on its own: PRs expire after 2 days if unmerged, patches are capped at 500 files, and protected-file edits automatically fall back to filing an issue instead of silently failing. It’s a small but deliberate guardrail set for a workflow that has write access to propose changes across the entire repo’s workflow surface — tight enough to keep blast radius small, generous enough to let Q actually fix things.

The interesting part isn’t any single fix — it’s the range. In three runs pulled from the same short window, Q handled a low-level infrastructure canary test, a cost-optimization tweak, and a state-persistence upgrade, each triggered by a different person from a different corner of the repository. That’s the value proposition of an on-demand workflow doctor: no scheduling, no queue, just /q and a clear ask.

Want to see how Q — or any other gh-aw workflow — is built? Explore the project at github.com/github/gh-aw.

Weekly Update – August 24, 2026

Mon, 24 Aug 2026 00:00:00 GMT

Another busy week for github/gh-aw! We shipped three pre-releases (v0.87.1, v0.87.2, and v0.87.4) and merged dozens of pull requests focused on safe-output reliability, compiler robustness, and internal reporting accuracy. Here’s what stood out.

Release Highlights

The v0.87.4 line of releases focused on compiler robustness, safe-output validation, and internal tooling and observability improvements across the agentic workflow pipeline.

Run steering (#55171): safe-outputs.create-pull-request.pre-create.steer: true introduced run-scoped feedback issues and injected prompting for agents to read comments containing the steer keyword. The configuration was subsequently moved to safe-outputs.steer, where it requires explicit issues: read without silently expanding workflow permissions.
gh aw models (#55148): a new CLI command surfaces catalog pricing, alias resolution, and observed automation models in one place.
Copilot SDK startup diagnostics (#55149): pre-ready crashes now surface the Copilot SDK’s startup stderr, making a previously opaque failure mode much easier to debug.
Automatic PR review dismissal ingestion (#55180): workflows can now ingest automatic pull request review dismissals as part of their safe-output processing.

Notable Pull Requests

Align daily workflow and merged-PR metrics: standardized the daily reports’ workflow population and merge-window comparisons so fleet-size and Copilot success-rate numbers stop drifting apart.
Fix lockfile-stats discussion category extraction and add loud self-check: the Lockfile Statistics report was silently reporting zero discussion categories due to a key mismatch in compiled .lock.yml parsing — now fixed, with a self-check to keep it from regressing quietly again.
Update detection analysis report to reflect gh-aw-detection default-on: now that gh-aw-detection defaults to enabled, the detection-analysis-report workflow correctly classifies unset/absent values instead of flagging them as misconfigured.
Migrate 30 copilot workflows to codex engine + copilot/mai-code-1-flash-picker: a large batch migration moving many Copilot-powered workflows onto the codex engine.
Render agentic engine in generated footers: workflow-generated content (like PR footers) now shows which engine produced it, improving traceability across the fleet.

Agent of the Week: PR Sous Chef

The tireless kitchen staff of the PR pipeline — it watches over open pull requests and keeps their descriptions, context, and footers fresh and useful.

This week pr-sous-chef ran three times in a single day (all successful, all on the pi engine), burning through roughly 76K tokens and racking up 8 safe-output items across its runs — including landing the new pre-create PR steering feature itself via #55171. Its most recent run alone produced 5 safe items in under 8 minutes, a tidy little burst of productivity right before this post went out.

Somewhat fittingly, the workflow that teaches other PRs how to listen to reviewer feedback (steer) shipped that very feature about itself — a small bit of “eating your own dog food” that we appreciated.

Usage tip: Reach for a pr-sous-chef-style workflow whenever your team’s biggest bottleneck is PR descriptions and footers going stale between review rounds — it keeps that metadata current without anyone lifting a finger.

→ View the workflow on GitHub

Try It Out

Grab the latest v0.87.4 release to try the initial pre-create PR steering configuration. Current workflows use safe-outputs.steer as described in #55792. As always, questions, bug reports, and contributions are welcome over at github/gh-aw.

One Small Error Message, One Big Feedback Loop

Sun, 23 Aug 2026 00:00:00 GMT

Most bug reports start with a person noticing something odd. This one started with a small scheduled script.

On August 23, the Daily Safe Outputs Conformance Checker spotted a possible gap in gh-aw’s MCP error handling. The immediate symptom was not dramatic: under the wrong conditions, a user could receive [object Object] instead of a useful error message. But the story that followed is a good reminder of what automated maintenance can look like at its best.

One check became issue #55014, a focused repair in PR #55042, and a preventative lint rule proposed in PR #55052. The interesting part is not any one of those artifacts. It is the loop between them.

A tiny signal worth following

Every day, the checker runs scripts/check-safe-outputs-conformance.sh against the Safe Outputs implementation. It collects the results, groups failures by severity and check ID, and turns important findings into actionable issues. High-severity failures cause a nonzero exit; the issue is then short-lived, so a newer run can replace stale information instead of growing an endless backlog.

Run #32621246743 raised MCE-006, the check for readable serialized error messages. At first glance, it looked like the checker had simply missed an abstraction: it searched mcp_server_core.cjs for direct calls such as String(e.message), while the core delegates formatting to getErrorMessage() in error_helpers.cjs.

That could have been the end of the investigation: another false positive to tune away. Instead, the generated issue followed the helper. It uncovered a real edge case. If code threw a plain object with a non-string message, the helper could fall back to String(error). For a value like { message: { reason: "x" } }, that means the person on the other end could see [object Object]—technically a string, but not an explanation.

Fix the bug—and improve the question

PR #55042 makes the intent explicit: when a non-Error object has a message property, preserve a string message or coerce that message value. Only objects without a message use the whole-object fallback. The accompanying tests cover numeric and non-primitive messages, turning the edge case into an expected behavior.

The repair also improves MCE-006 itself. The checker still accepts direct coercion in the MCP core, but it now recognizes the shared-helper path when getErrorMessage() safely handles non-string messages. That is an important distinction: good conformance checks protect a property, not a particular spelling of the implementation.

Then ask: where else does this pattern live?

The repair was not treated as a one-off. The scheduled ESLint Miner mines recent issues and discussions, scans actions/setup/js, selects one low-false-positive rule, validates it, and opens at most one draft PR. Its August 23 run used MCE-006 as the seed for a broader question: is this pattern hiding elsewhere?

The result is the proposed no-string-fallback-for-non-string-message rule in PR #55052. It looks for a narrow shape: code confirms that x.message is a string, returns it when it is, then falls back to String(x) instead of String(x.message). The rule is a warning, not an automatic rewrite, because a readable fallback still needs local judgment.

The miner found four live occurrences in actions/setup/js: dispatch_workflow.cjs, route_slash_command.cjs, log_parser_shared.cjs, and safeoutputs_cli.cjs. Each deserves its own fix decision. The rule simply ensures that this particular sharp edge is no longer invisible.

The real product is the feedback loop

The lasting outcome here is not only a better error message. It is a maintenance system that keeps learning: a specification defines the promise, a daily check tests it, an issue investigates the signal, a small repair closes the gap, and a lint rule helps prevent the pattern from returning.

That is the kind of automation worth building. It does not replace engineering judgment; it creates more opportunities to apply it where it matters most. Follow github/gh-aw for the status of the repair and rule proposals, and inspect the linked workflows to adapt this feedback loop in your own repository.

Agent of the Day – August 21, 2026

Fri, 21 Aug 2026 00:00:00 GMT

Agent of the Day – August 21, 2026: The Tidy-Upper

Big refactors get all the attention, but most technical debt accumulates in tiny increments — a copy-pasted loop here, a redundant conditional there. Nobody schedules time to fix these on their own; they’re too small to justify a dedicated sprint and too easy to overlook during a busy review. Today’s spotlight is built specifically for that gap: a workflow that hunts for small, low-risk simplification opportunities every day and quietly cleans them up.

Agent of the Day: The Tidy-Upper

We’re calling this persona The Tidy-Upper, and it belongs to Code Simplifier, a scheduled gh-aw workflow that runs daily against the github/gh-aw repository. Rather than chasing sweeping architectural changes, it scans a deterministic list of candidate files, scores them for simplification opportunities, and picks the single clearest, lowest-risk target for that day’s pass.

The Tidy-Upper’s August 20 run is a great example of its discipline. Working from a pre-computed candidate list (source-files.json) rather than re-querying GitHub for history — a deliberate token-efficiency guardrail baked into the workflow — it reviewed 20 candidate files, including add_comment.cjs, add_labels.cjs, and purity_scan.go, and deferred all of them as too large or too risky for an unattended pass. Instead it zeroed in on .squad/templates/ralph-triage.js, where the findMember() helper ran four separate sequential loops over a roster array — one each for exact name match, exact role match, name substring match, and role substring match.

Its fix replaced those four loops with a single MEMBER_MATCH_STRATEGIES array of match predicates, tried in order via one roster.find(...) call. The behavior is preserved exactly: same priority order, same normalization, same early-return semantics. It’s the kind of change a human reviewer nods along to instantly, precisely because nothing risky happened — just less code doing the same job. The workflow validated its own work with node --check, confirmed make build succeeded, and noted honestly that no existing test harness covers that standalone template script, rather than pretending otherwise. That PR shipped as PR/issue #54129.

The very next day, run #268 on August 21 kept the streak going, again completing successfully and landing a follow-up pull request — PR #52622 — continuing the same pattern of small, verifiable wins. Across its last three runs, the workflow logged zero errors, zero missing tools, and a near-perfect firewall record (0–1% blocked requests out of well over a hundred network calls each run), evidence that it’s operating exactly within its intended, tightly scoped lane.

What’s notable about the Tidy-Upper isn’t ambition — it’s restraint. It explicitly reviewed larger, juicier refactor targets and said “not today” because the risk-to-value ratio wasn’t right for an unattended agent. That kind of self-imposed conservatism is what makes daily automated code changes trustworthy enough to actually merge.

Try it yourself

Curious how a workflow like Code Simplifier is put together, or want to spin up your own daily housekeeping agent? Check out github/gh-aw and start building.

GitHub Agentic Workflows | Blog

Agent of the Day – September 10, 2026

Agent of the Day: Package Specification Librarian

Try It Yourself

Agent of the Day – September 9, 2026

Agent of the Day: PureLock

Agent of the Day – September 8, 2026

Agent of the Day: CLI Version Checker

Agent of the Day – September 7, 2026

Agent of the Day: Dead Code Removal Agent

Weekly Update – September 7, 2026

Release: v0.88.4

What’s New

Bug Fixes & Improvements

Notable Pull Requests

Agent of the Week: dead-code-remover

Try It Out

MicroVM Support Is Consolidating on Cloud Hypervisor

What changes

Migrating existing workflows

Agent of the Day – September 3, 2026

Agent of the Day: Issue Monster

Agent of the Day – September 2, 2026

Agent of the Day – September 2, 2026: The Complexity Cop

What the logs actually show

Built for restraint, not volume

Why this matters for gh-aw

Try it yourself

Agent of the Day – September 1, 2026

Agent of the Day: PR Sous Chef

Sandbox Security Options Are Now Runtime Profiles

Migrate existing workflows

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

Fewer tokens spent on tool schemas

A smaller, more auditable attack surface

MCP is still available, just not built-in

Agent of the Day – August 31, 2026

Agent of the Day: Issue Arborist

Weekly Update – August 31, 2026

Release Highlights

Notable Pull Requests

Agent of the Week: AI Moderator

Try It Out

Agent of the Day – August 28, 2026

Agent of the Day: ESLint Refiner

Agent of the Day – August 26, 2026

Agent of the Day – August 26, 2026: The CLI Archivist

Agent of the Day: CLI Consistency Checker

Agent of the Day – August 25, 2026

Agent of the Day – August 25, 2026: The Cookie Monster of Issues

Agent of the Day: Issue Monster

Agent of the Day – August 24, 2026

Agent of the Day – August 24, 2026: The Workflow Doctor

Agent of the Day: The Workflow Doctor

Weekly Update – August 24, 2026

Release Highlights

Notable Pull Requests

Agent of the Week: PR Sous Chef

Try It Out

One Small Error Message, One Big Feedback Loop

A tiny signal worth following

Fix the bug—and improve the question

Then ask: where else does this pattern live?

The real product is the feedback loop

Agent of the Day – August 21, 2026

Agent of the Day – August 21, 2026: The Tidy-Upper

Agent of the Day: The Tidy-Upper

Try it yourself

Why this matters for `gh-aw`