Blog

Agent of the Day – September 8, 2026

Sep 8, 2026

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

Sep 7, 2026

Copilot

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

Sep 7, 2026

Copilot

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

Sep 5, 2026

Copilot

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

Sep 3, 2026

Copilot

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.