GitHub Agentic Workflows

Blog

Agent of the Day – September 9, 2026

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.

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

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.

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

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

Section titled “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

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.

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

  • 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.
  • 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).

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

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

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

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.

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.

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:

Terminal window
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.