GitHub Agentic Workflows | Blog

Weekly Update – August 10, 2026

Mon, 10 Aug 2026 00:00:00 GMT

It’s been another busy week in github/gh-aw, with two notable releases and dozens of merged pull requests touching everything from compiler safety to CI stability. Here’s what shipped.

Release: v0.86.1

v0.86.1 landed on August 7th with a broad set of compiler safety fixes, new gh aw fix diagnostics, and expanded engine support.

What’s New

Guided gh aw fix diagnostics: The tool now offers a guided fix for restricted tools.bash allow-listing on engines that ignore it (#51102), plus tips for known external engines like opencode and crush missing their import (#51088).
Expanded engine support: Added shared engine definitions and smoke tests for Pydantic AI (#51161), plus new example workflows for the aider, cursor, and kiro definition-based engines (#51166).
PureLock initiative: Introduced a daily pure-function maximum-coverage test workflow (#51107) that is progressively locking down core compiler functions with dedicated test suites (#51167, #51119).
Safe-outputs improvements: Fixed add_labels failing on pull requests in issue-intent paths (#51168) and replaced loosely-typed bool-or-expression fields with *TemplatableBool for safer config typing (#51097).

Release: v0.86.0

v0.86.0 shipped earlier the same day as a heavy security and reliability hardening pass across secret redaction, MCP gateway logging, and threat-detection resilience.

Security & Redaction

Secrets can no longer leak through logs or artifacts. Redaction is now enforced in step summaries (#50777), patch/bundle artifacts (#50778), and MCP gateway diagnostic logs (#50961).
URL handling hardened: userinfo is now stripped from logged URLs and rejected URLs are no longer logged in full (#50776).
upload_artifact safe-output now restricts uploads to canonical allowed roots and rejects sensitive paths (#50779).

Notable Pull Requests

Beyond the releases, the team merged a steady stream of fixes and quality-of-life improvements:

Skip stale review-thread node IDs instead of failing safe_outputs — makes resolve_pull_request_review_thread more resilient to stale GraphQL node IDs.
Grant agentic engines read/write access to /tmp/gh-aw in AWF sandbox — smooths out sandboxed engine runs that need scratch space.
Fix recurring gh-aw-firewall digest-pin loss on DefaultFirewallVersion bumps — keeps firewall image pins from silently drifting on version bumps.
Add explicit end marker syntax for inline skills and sub-agents — clarifies where inline skill and sub-agent content ends in workflow markdown.
Fix Copilot path portability across runners — irons out cross-platform path handling for the Copilot engine.

Agent of the Week: PureLock

PureLock is the daily workflow that quietly locks down up to three uncovered pure Go functions per run, writing dedicated test suites so core compiler logic doesn’t regress unnoticed.

This week PureLock ran three times — once from its daily schedule and twice via manual dispatch — clocking in at 15 to 22 minutes per run and burning through roughly 60,000 tokens total. All three runs completed successfully and stayed strictly read-only until their final PR, methodically chipping away at coverage gaps. Its handiwork showed up directly in this week’s release notes, with #51586 locking down sameExpr, addAllowedToNetwork, and rpcEntryToTimelineEvent with pure-function test suites.

Give it a function name like simplifyDataSchemaNode and it will happily go write exhaustive tests for it without complaint — the kind of unglamorous, repetitive work that keeps a growing Go codebase honest one pure function at a time.

Usage tip: Pair a coverage-locking workflow like this with your CI’s coverage gate so newly written tests actually prevent regressions instead of just padding a report.

→ View the workflow on GitHub

Try It Out

Update to v0.86.1 today to get the latest diagnostics and security hardening. As always, feedback and contributions are welcome in github/gh-aw.

Weekly Update – August 3, 2026

Mon, 03 Aug 2026 00:00:00 GMT

Another packed week in github/gh-aw: five releases (v0.83.4 through v0.84.2) and over 100 merged pull requests. This week’s theme was hardening — shell script safety, container security, and closing sneaky edge cases in the safe-outputs pipeline.

Release Highlights

v0.84.2 — August 1

A maintenance release focused on stability and security, with no breaking changes.

Fixed an argument injection vulnerability (CWE-88) in the git archive fallback path (#49500)
Hardened the PR Description Updater against one-shot safe-output exhaustion (#49463)
Stacked PR runs now default to top-of-stack, with a configurable on.pull_request.max-stack option extended to pull_request_review gating (#49420, #49453)
Explicit auto-merge strategies are now supported in safe-outputs.create-pull-request (#49412)
CLI version bumps across the board: Copilot 1.0.77, Pi 0.83.0, Playwright Browser v1.62.1, Syft v1.50.0, Grype v0.116.1 (#49521)

v0.84.0 and v0.84.1

These releases rolled out a shellcheck linting phase for generated run steps in the compile pipeline, plus continued security patching for third-party MCP containers.

Notable Pull Requests

feat: shellcheck disabled by default, opt-in via --shellcheck/--validate, parallel execution — the new shellcheck gate ships opt-in first, so teams can adopt it on their own schedule while the compiler still catches real script bugs when enabled.
fix(security): disable semgrep/semgrep container — Critical/High CVEs and security: remove mcp/markitdown container (849 CVEs) — proactive removal of MCP containers with unpatched vulnerabilities, keeping the default toolset safe by default.
Fix gh-aw-node brace-expansion patch (GHSA-mh99-v99m-4gvg) — replaced a brittle npm --prefix overlay with a temp-dir copy, closing a supply-chain gap.
Add first-class agent job gating via jobs.agent.needs and jobs.agent.if — workflow authors can now express fine-grained dependencies and conditions directly on the agent job.
Rescue completed watchdog-fired Copilot runs from false authentication_failed classification — one of several reliability fixes that reduce false-positive failure reports in the dashboards.

Agent of the Week: Dead Code Removal Agent

Every day, this quiet janitor scans the codebase for functions nobody calls anymore — and deletes them, no drama required.

This week it stayed characteristically productive: across its last three scheduled runs it logged zero errors and zero warnings, chewing through roughly 43K tokens total, and its August 1st run (#49801) walked away with four confirmed dead functions removed in a single pass. One earlier run did hit a rough patch — a merge-conflict-heavy branch tripped it into a “risky” classification — but it shrugged that off and came back clean the very next scheduled run.

It’s the kind of agent that never asks for credit: three runs, one clean PR, and a repo that’s just a little tidier than it was last Tuesday.

Usage tip: Schedule dead-code cleanup agents like this one on a low-traffic cadence (daily or every few days) so PRs stay small, reviewable, and easy to revert if a “dead” function turns out to have a reflection-based caller.

→ View the workflow on GitHub

Try It Out

Update to v0.84.2 and give the new shellcheck flags a spin with --validate. As always, bug reports, security findings, and PRs are welcome in github/gh-aw.

Weekly Update – July 27, 2026

Mon, 27 Jul 2026 00:00:00 GMT

It was a busy week in github/gh-aw — four releases landed between Monday and Friday, each one stacking new capabilities on top of the last. Here’s a look at what shipped.

Releases This Week

v0.83.0 — July 22

A focused security and developer-experience release.

Three new ESLint rules ship in one go: stringsjoinone catches unnecessary single-element strings.Join calls, no-setfailed-then-exit-zero prevents masked CI failures, and require-execfilesync-try-catch enforces error handling around execFileSync.
Sub-30s make test-unit — tests now run impacted packages first, giving you fast feedback without waiting for the full suite.
close_issue state-reason — agents that close issues can now pick the closure reason dynamically (completed, not-planned, etc.), making your workflows more expressive.

v0.83.1 — July 23

This one expanded gh aw compile into a proper security pipeline.

Container vulnerability scanning with Grype (#47474) — compile now checks gh-* workflow container images for CVEs before deployment.
License auditing and YAML linting are also now part of the compile pass, catching problems before they hit production.

v0.83.2 — July 24

Reliability and security fixes.

Smarter gh aw add (#47690) — local skill references are now auto-rewritten to fully-qualified specs on gh aw add, so workflows stay portable when you share them.
Shell injection detection improvements and a WIF auth regression fix round out the security hardening.

v0.83.3 — July 25

The biggest release of the week.

Git argument injection fix (VULN-001) (#47957) — a security fix for unvalidated ref/path values in remote import fallbacks that could allow command injection via crafted ref names.
GraphQL injection fix (#47952) — resolved two code scanning alerts for GraphQL injection in getOwnerNodeId.
GitHub MCP Server v1.7.0 (#47923) — all workflows now get the latest MCP tool improvements out of the box.
stringsconcatloop linter (#47894) — a new Go analyzer catches string += inside loops and guides you toward strings.Builder.
Post-update SHA integrity validation (#47959) — actions-lock entries are now SHA-verified after updates, closing a supply-chain tampering vector.
WASM panic recovery (#47854) — playground users will no longer see stuck promises after a compile panic.

Agent of the Week: Daily GitHub Docs SEO Optimizer

The newest addition to the workflow roster — quietly making sure GitHub Docs can actually find gh-aw when you need it.

daily-github-docs-seo-optimizer was shipped in v0.83.3 (#47975) and immediately got to work. Its job is to scan GitHub Docs pages and identify minimal, targeted updates that would help Copilot CLI surface Agentic Workflows as solutions to repository automation tasks. It’s not trying to game search engines — it’s trying to make sure that when a developer asks Copilot “how do I automate issue triage?”, the answer actually mentions gh aw.

Fresh off the assembly line this week, it hasn’t accumulated a rich log history yet (give it time), but the design is interesting: it runs daily on gpt-5.4 with a bare driver and creates issues prefixed [github-docs-seo] when it finds documentation gaps worth flagging. No filesystem writes, no PR spam — just targeted observations filed as issues for humans to review.

Usage tip: If you’re maintaining a library or CLI tool, a similar workflow can continuously audit whether your documentation appears in the right Copilot/LLM context for common developer questions — without needing a dedicated SEO team.

→ View the workflow on GitHub

Try It Out

Upgrade to v0.83.3 to get the full set of security fixes, the new GitHub MCP Server v1.7.0, and the expanded linter suite. Questions and contributions are always welcome in github/gh-aw.

Weekly Update – July 20, 2026

Mon, 20 Jul 2026 00:00:00 GMT

Another action-packed week in github/gh-aw! Between a fresh release, a firewall bump, improved rootless runner support, and a thoroughly redesigned workshop experience, there was plenty to keep the bots busy.

Release: v0.82.13

v0.82.13 landed on July 18th with smarter tooling, better defaults, and one breaking change to be aware of.

! Breaking Change

gh aw add now rejects packages with aw.yml config (#46273): If you maintain packages that include an aw.yml configuration file, update them before upgrading — the CLI will now refuse to install them outright.

What’s New

Auto-configure COPILOT_PROVIDER_WIRE_API from the model catalog (#46156): The CLI now resolves the provider wire API endpoint automatically, so you don’t have to set it by hand.
Default-on issue intent metadata (#46207): set_issue_type, set_issue_field, and add_labels now emit intent metadata by default — richer audit trails with zero extra config.
NO_COLOR support (#46197): The CLI now honours the NO_COLOR environment variable for cleaner output in CI and accessibility-focused terminals.
Stronger ESLint alias detection (#46365): The no-core-setoutput and exportvariable rules now catch aliased and destructured @actions/core bindings, closing a common bypass pattern.

Notable Pull Requests

Firewall bump to v0.27.37: The default gh-aw-firewall was updated from v0.27.35 to v0.27.37, bringing ANTHROPIC_AUTH_TOKEN credential isolation, ~/.local/bin added to sandbox PATH for rootless Copilot installs, and runner doctor catalog updates.
Rootless flag for ARC/DinD runners: install_copilot_cli.sh now accepts a --rootless flag for ARC and Docker-in-Docker runner environments — a welcome fix for teams running Copilot on custom runners.
New timenowsub linter: The linter-miner contributed another Go linter that flags time.Now().Sub(t) and auto-rewrites it to the idiomatic time.Since(t). Small but satisfying.
Workshop redesign: The workshop has been moved to /workshop/, simplified to match docs styling (#46593), and now shows step counts on entry and scenario cards (#46622) — making it much easier to gauge how much is left before you start.
MCP toolsets sync: GitHub MCP toolset mappings were synced with the upstream github-mcp-server main branch, keeping tool definitions up to date.

Agent of the Week: Avenger

The CI guardian who never sleeps — Avenger runs every hour, checks whether CI is passing, and if it’s not, merges main, runs recompile/fmt/lint/test, and opens a PR with any fixable issues.

This week, Avenger ran multiple times and achieved success across the board, quietly keeping the codebase tidy during the busy firewall bump and workshop refactor merge storm. Each run it faithfully pulled in the latest main, ran the full quality gauntlet, and — finding nothing broken — went back to sleep without making a fuss.

The highlight of Avenger’s week was its run right after the v0.27.37 firewall bump landed, where it dutifully checked that all 258 recompiled .lock.yml files hadn’t introduced any CI regressions. They hadn’t. Avenger nodded once and clocked out.

Usage tip: Avenger shines in repos where automated PRs (dependency bumps, codegen, lock file updates) can quietly break CI — it catches those regressions within the hour so humans don’t have to.

→ View the workflow on GitHub

Try It Out

Grab v0.82.13 and take the redesigned workshop for a spin. As always, feedback and contributions are welcome in github/gh-aw.

Weekly Update – July 13, 2026

Mon, 13 Jul 2026 00:00:00 GMT

Another active week in github/gh-aw! We shipped v0.82.8, landed several impactful features, and squashed a frustrating Docker authentication bug that had been interrupting sbx-runtime workflows.

Release: v0.82.8

v0.82.8 published on July 11th with a broad set of reliability and security improvements.

What’s New

gVisor container runtime (#44796): Set sandbox.agent.runtime: gvisor in your workflow frontmatter to run the agent inside a gVisor sandbox for stronger isolation — great for workflows processing untrusted input.
Shared partials can declare sandbox.agent.mounts (#44500): Partial workflow files can now define mount configurations that get merged into the parent, enabling reusable sandbox setups without copy-paste.
AI authorship disclosure header (#44497): A new disclosure-header safe-output message type lets agents declare AI authorship inline in PR comments and issues.
gh aw add resolves transitive uses: references (#44763): Importing a workflow partial now automatically pulls in any nested imports — no more manual dependency hunting.
OAuth token failures surface in conclusion job (#44777, #44756): Token failures are no longer silently swallowed — they now show up where you’d expect.

Notable Pull Requests This Week

docker-sbx runtime support — You can now run your agent inside a KVM-isolated Docker sbx microVM (sandbox.agent.runtime: docker-sbx) while keeping infrastructure containers on the host. Full hardware-virtualization isolation for workloads that need it.
Emit sbx credential refresh before agent execution — Fixes those maddening intermittent "user is not authenticated to Docker" errors. Docker Hub OAuth tokens from the daemon-setup step could expire by the time the agent ran. Now a fresh sbx login runs immediately before agent execution for all sbx-runtime workflows.
private-to-public-flows: allow frontmatter field — Wires the full frontmatter → struct → gateway JSON pipeline for tools.github.private-to-public-flows, letting you opt specific MCP servers out of sink-visibility enforcement when you explicitly trust those flows.
Bump gVisor release to 20250707.0 — Keeps the pinned gVisor release current with upstream security and reliability patches.
Add missing copilot safe-output fixture files — Adds fixtures for close-discussion, assign-to-agent, assign-to-user, and unassign-from-user, filling gaps in the safe-output test suite.

Agent of the Week: aw-failure-investigator

Your on-call teammate who never sleeps — it wakes up every 6 hours, scans recent workflow run failures, and files GitHub issues so problems don’t fall through the cracks.

This week aw-failure-investigator ran three times across July 11–12, filing 3 issues in total (2 in one run, 1 in another). Each run clocked in around 15 minutes and consumed 250+ AI credits running on claude-opus-4-8 — because when you’re investigating failures, you don’t want to cut corners. The July 11th run had its own failure (meta!), but bounced back cleanly on its next scheduled cycle.

In one particularly busy shift it made 13 GitHub API calls in 15 minutes, which is either impressive efficiency or evidence that it found a lot to worry about. Probably both.

Usage tip: Pair aw-failure-investigator with a label-based notification rule so the right team gets pinged when it files an issue — that way failures surface asynchronously without requiring anyone to watch the Actions tab.

→ View the workflow on GitHub

Try It Out

Update to v0.82.8 and explore the new docker-sbx and gvisor sandbox runtimes. If you’ve been hitting Docker auth errors on sbx workflows, the credential refresh fix should put those to rest. Contributions and feedback are always welcome at github/gh-aw.

Weekly Update – July 6, 2026

Mon, 06 Jul 2026 00:00:00 GMT

It was a productive week in github/gh-aw — with dozens of pull requests landing across the compiler, linters, JavaScript setup scripts, and documentation. Here’s a look at the highlights.

Notable Pull Requests

fix(compiler): auto-add `pre_activation` to `safe_outputs`/`conclusion` needs

A sneaky compiler bug was generating skillet.lock.yml files with broken actionlint expressions: safe_outputs and conclusion jobs referenced ${{ needs.pre_activation.outputs.skill_name }} without actually declaring pre_activation as a dependency. This fix auto-wires the dependency whenever a message template references pre_activation outputs — no more cryptic expression errors in generated lock files.

refactor(linters): consolidate AST/context helpers into `internal/astutil`

The linter suite had quietly grown several copies of the same helper functions — enclosingFuncType, context-type resolution, OS-call detection — scattered across individual analyzers. This PR gathers them all into a single pkg/linters/internal/astutil package and rewires the affected analyzers, eliminating drift risk and making future linter work easier to reason about.

ambient-context: reduce copilot-agent-analysis first-request size by ~28%

copilot-agent-analysis was the largest ambient-context payload at 27,299 characters — most of it content that’s rarely needed at runtime. By gating cold-start rebuild content behind an optional import, this PR trims the first-request size to 11,876 characters, cutting token costs on every agent activation that uses this analysis path.

Add shared prompt quality gate for plateaued agent-review workflows

Agent effectiveness scores had been stuck around 61–62 for several weeks — a signal that prompt design, not runtime bugs, was the limiting factor. This PR introduces a reusable quality rubric shared across analyzer and reviewer workflows, giving those workflows a concrete target for what “good” looks like and a path out of the plateau.

fix(setup/js): numeric coercion, setOutput stringification, and async entrypoint cleanup

A sweep across 23 files in actions/setup/js replaced global isNaN (which silently coerces inputs) with Number.isNaN, fixed core.setOutput value types, and cleaned up unhandled async rejections. Small correctness improvements that prevent subtle runtime surprises in CI steps.

Agent of the Week: Weekly Issue Summary

Your Monday morning data journalist — scans all issue activity from the past week and compiles trends, charts, and resolution statistics into a single digest comment.

weekly-issue-summary has been running quietly every Monday around 3 PM UTC, pulling 30 days of issue data, generating CSV trend files, and rendering two charts: one for issue open/close velocity and one for resolution time distributions. In its last three runs it made 13 GitHub API calls each time and burned through roughly 59 AI credits — efficient for a workflow that touches every open and closed issue in the repo. Two of the three runs succeeded without any write-side effects, posting the full digest to a tracking issue, while one run hit a timeout on the data preparation phase and bailed cleanly.

The June 15th failure is the fun part: the observability report flagged it with the note “this run consumed a heavy execution profile for its task shape” and gently suggested the team might want to swap in a smaller model. The workflow took the feedback in stride and came back the following Monday working perfectly.

Usage tip: Pair weekly-issue-summary with a label strategy — the chart breakdowns are most useful when issues are consistently labeled, since resolution-time distributions get interesting when you can split them by category.

→ View the workflow on GitHub

Try It Out

All of this week’s changes are already on main — pull the latest and run gh aw compile to pick up the compiler and linter improvements. Got feedback or spotted something worth fixing? Contributions are always welcome at github/gh-aw.

Weekly Update – June 29, 2026

Mon, 29 Jun 2026 00:00:00 GMT

A big week at github/gh-aw! Canvas extensions land, security coverage expands, and the runtime stack gets a fresh set of bumps. Here’s everything that shipped between June 22 and June 29.

New: Copilot Canvas Extension for Agentic Workflows

PR #42137 ships a project-scoped GitHub Copilot Canvas extension — a GitHub-styled dashboard you can open right inside the Copilot app to manage agentic workflows without leaving your editor.

The extension supports:

Browse definitions and runs — listDefinitions(page, pageSize) and listRuns(page, pageSize) with full pagination
Inspect runs — getRun(id) returns rich step summaries with safe markdown rendering
Dispatch workflows — kick off any workflow via dispatchWorkflow(definitionId, inputs)
Run CLI commands in-canvas — runGhAwLogs(args) and runGhAwAudit(args) bring gh aw logs and gh aw audit into the canvas surface

The UI is built with Alpine.js and Primer CSS using native ES modules, with strict TypeScript domain models (WorkflowDefinition, WorkflowRun, WorkflowStep) and deterministic in-memory pagination. This is a high-impact addition for anyone who manages agentic workflows day-to-day.

Paired with this, PR #42147 adds a new create-canvas skill that guides you through authoring, validating, and debugging canvas extensions — covering the full lifecycle from scaffolding via extensions_manage to exercising actions with invoke_canvas_action.

Security: Sandbox Hardening Reaches 80%

PR #42119 is a satisfying milestone: sandbox.agent.sudo: false is now set on 206 out of 257 workflows (80.16%). This PR added the flag to 79 additional workflow specs and regenerated the matching lock files. Provenance-managed (source:) workflows were left untouched. If your workflow audits were catching a lot of missing sandbox flags, this cleans up the bulk of them.

Code Scanning Fixer: Now Covers All Severity Levels

Previously, code-scanning-fixer only tackled critical and high alerts. PR #42139 removes that filter, expanding the workflow to enumerate all open code scanning alerts and prioritize them by severity:

critical > high > medium > low (using rule.security_severity_level when available)
Falls back to error > warning > note when security severity is absent

The selection logic, no-op messaging, and PR body copy were all generalized to work across every severity level. If you had a backlog of medium/low findings quietly aging, this workflow will now start chipping away at them.

Runtime: mcpg v0.3.32 + Firewall v0.27.13

PR #42146 bumps two default runtime components:

Component	Old	New
gh-aw-mcpg	v0.3.31	v0.3.32
gh-aw-firewall	v0.27.12	v0.27.13

All container image digests are SHA-pinned in action_pins.json. Low-risk, no migration needed.

Other Merges Worth Noting

PR #42115 — linter-miner added a new osgetenvlibrary analyzer that flags os.Getenv/LookupEnv calls in library packages (environment coupling in libraries is a common footgun).
PR #42118 — Prevents step-summary conversation truncation when agent output contains fenced code blocks.
PR #42117 — Slash-command footer hints now render correctly for custom safe-output footers.
PR #42112 — Fixed a cache-memory history path bug in Agent Persona Explorer that was triggering false cache_memory_miss errors.

Agent of the Week: agent-persona-explorer

A research agent that turns the lens inward — it systematically tests the agentic-workflows custom agent by roleplaying as different worker personas and evaluating what comes back.

Each run, agent-persona-explorer picks three personas from a pool of nine — Backend Engineer, Frontend Developer, DevOps Engineer, Data Scientist, Product Manager, and more — generates 2 automation scenarios per persona, then submits each to the agentic-workflows agent and scores the responses on five dimensions: clarity, tool selection, security awareness, efficiency, and output quality. It stores a rotation history in cache memory so it never tests the same persona slice twice in a row. Results are published as a GitHub issue labeled agent-research.

The workflow ran three times in the past week. Two runs succeeded cleanly, but the first failed due to a cache-memory path mismatch — which was fixed in PR #42112 within hours. The two successful runs consumed around 24 AIC each, used gpt-5.4 for analysis, and made 13 GitHub API calls to gather workflow context before synthesizing findings.

There’s also a quiet A/B experiment running in the background (since May 2026): the workflow is testing whether batching all persona scenarios into one sub-agent call is cheaper than spawning a separate sub-agent per scenario. The hypothesis is a ≥20% token reduction — and with 14 minimum samples required for a t-test conclusion, the jury is still out.

Usage tip: If you’re building or tuning a custom agent, agent-persona-explorer-style testing is a powerful way to surface blind spots — run it against your own agent to see how it handles requests from personas you didn’t design for.

→ View the workflow on GitHub

Check out the github/gh-aw repository for the full list of changes, and give the new Canvas extension a spin if you’re managing agentic workflows in Copilot.

Custom Linters in Practice: Sergo, Linter Miner, and LintMonster

Fri, 26 Jun 2026 00:00:00 GMT

gh-aw now registers 35 custom Go analyzers in cmd/linters/main.go. That linter surface is not maintained by hand alone. It is grown, audited, and applied by three separate workflows:

Linter Miner proposes new analyzers from recurring patterns.
Sergo stress-tests those analyzers for false positives, false negatives, and suppression gaps.
LintMonster runs the custom suite and turns findings into tracked cleanup work.

The interesting part is not that each workflow exists. It is that they form a loop: one workflow adds lint rules, another challenges them, and a third drives the codebase toward compliance.

Linter Miner keeps adding new rules

The workflow definition is explicit about its job: mine discussions, issues, and Go source, pick one new linter idea, implement it, and open a PR. GitHub search currently shows a long run of [linter-miner] PRs, and the recent examples are concrete:

fprintlnsprintf flags fmt.Fprintln(w, fmt.Sprintf(...)) and links to ADR 34498.
timeafterleak catches time.After(...) inside for+select loops.
errorfwrapv flags fmt.Errorf(...%v..., err) where %w should preserve the error chain.
wgdonenotdeferred catches non-deferred sync.WaitGroup.Done() calls.
lenstringsplit rewrites len(strings.Split(s, sep)) to strings.Count(s, sep)+1 when the separator is provably non-empty.
stringreplaceminusone rewrites strings.Replace(..., -1) to strings.ReplaceAll(...).

This is not a one-off burst. The same theme appears in the blog’s own weekly updates: May 25, June 15, and June 22. Those posts document fprintlnsprintf, timeafterleak, errorfwrapv, and deferinloop as shipped work rather than aspirational ideas.

Sergo pressure-tests the linters after they land

Where Linter Miner expands the rule set, Sergo does the adversarial follow-up. The workflow is focused on actionable Go analysis using Serena, and its issue history shows a steady pattern: find a precision gap, write a tightly scoped issue, and let the next PR harden the analyzer.

The clearest evidence is the issue-to-PR chain:

Issue #40244 found that errstringmatch only handled strings.Contains(err.Error(), ...); PR #40248 extended coverage to HasPrefix, HasSuffix, EqualFold, Index, LastIndex, and Compare.
Issue #41377 found missing //nolint: support across four context-family linters; PR #41382 added suppression parity.
Issue #41376 found a false negative in manualmutexunlock when two struct instances shared the same mutex field; PR #41383 fixed the keying model.
Issue #40947 found that wgdonenotdeferred missed goroutine closures launched inside loops; PR #41026 fixed the function-literal scope boundary.
Issue #41163 found that lenstringsplit mishandled an empty raw-string separator; PR #41188 fixed the false positive and the broken autofix.

There is also useful evidence in the failures. Sergo’s Issue #40243 bundled several package-identity precision fixes into one direction, and PR #40247 closed unmerged after sprawling into a large branch. The narrower follow-up work still landed, including PR #40248. That is a good sign: the workflow is producing reviewable problems, not just optimistic reports.

LintMonster turns diagnostics into repository work

LintMonster operates later in the loop. It runs make golint-custom, groups findings by root cause, creates or updates issues, and can assign up to three Copilot agent sessions to fix them.

Its evidence trail is easy to follow:

Issue #40932 grouped four resource-lifecycle and context-propagation findings; PR #41589 merged the targeted fixes.
Issue #40933 tracked hard-coded path constants; PR #41611 replaced the flagged literals with existing constants.
Issue #39314 established an authoritative function-length backlog for 653 findings.
Issue #41466 refreshed that same backlog at 660 findings and kept it consolidated instead of spawning duplicate tracking issues.

This is what makes the custom linter suite operational instead of decorative. Rules only matter if they change the repository. LintMonster is the workflow that turns diagnostics into queues, slices, assignments, and merged cleanup work.

Why the three-workflow loop matters

Taken together, the workflows separate three jobs that usually get conflated:

Invent a rule from a real pattern. Linter Miner does this with new analyzers such as timeafterleak and lenstringsplit.
Challenge the rule’s correctness. Sergo does this with issues such as #40947 and #41163.
Apply the rule to production code. LintMonster does this with issue-to-PR chains such as #40932 → #41589 and #40933 → #41611.

That split is why the system looks durable. New rules keep arriving. Old rules keep getting corrected. The repository keeps absorbing the results.

Further evidence

If you want to inspect the trail directly, start here:

Source workflows: Linter Miner, Sergo, LintMonster
Linter registry: cmd/linters/main.go
ADRs: 34498, 39133, 40837, 41090, 41285
Search views: [linter-miner] PRs, label:sergo issues, label:lint-monster issues

This is a useful pattern beyond gh-aw: treat static analysis as a living workflow system, not just a binary that runs in CI.

Weekly Update – June 22, 2026

Mon, 22 Jun 2026 00:00:00 GMT

Another packed week at github/gh-aw! Over 20 pull requests merged between June 15 and June 22, covering a significant performance regression fix, a new Go linter, a major feature flag rollout, and a handful of targeted reliability improvements. Here’s what shipped.

Performance: +320% Compiler Regression Fixed

PR #40662 fixes a nasty regression in BenchmarkCompileComplexWorkflow that had quietly pushed compile times from ~3 ms/op to ~12.7 ms/op — a 320% slowdown. The culprit was validateTemplateInjection triggering a full yaml.Unmarshal on every pass through hasAnyExpressionInRunContent, even when skipValidation=true (the default in NewCompiler()). Eliminating that redundant unmarshal brings benchmark performance back to baseline. If your workflows felt slower to compile lately, this is the fix.

New Linter: `deferinloop`

PR #40679 adds a new Go analysis linter — deferinloop — that flags defer statements placed inside for-loop bodies. A defer inside a loop doesn’t fire at the end of each iteration; it fires when the enclosing function returns, causing resource leaks (file handles, connections) and confusing LIFO cleanup ordering. gocritic covers this pattern but is currently disabled due to golangci-lint v2 bugs, so this custom analyzer fills the gap and is now enforced in CI.

`gh-aw-detection` Rolls Out to 50% of Workflows

PR #40698 expands the gh-aw-detection feature flag from 20% (43 workflows) to 50% of agentic workflows (107 out of 214). The rollout targets workflows alphabetically and adds features: gh-aw-detection: true to the 64 newly included workflows. If you’re watching detection coverage metrics, expect a notable jump.

Reliability Fixes

JSON-RPC Error Handling

PR #40715 fixes a bug where handleMessage in the MCP server was surfacing [object Object] in error responses. The root cause: the catch block used String(e) for non-Error thrown values, but safe_outputs_handlers.cjs throws plain objects for validation errors — giving callers a useless stringification. The fix detects plain objects and serializes them correctly, and also enforces valid JSON-RPC error codes for all thrown values.

Skillet Sparse Checkout Path Typing

PR #40684 fixes a sparse checkout path typing issue in Skillet’s pre-activation skills checkout. A type mismatch was causing silent failures when resolving sparse checkout paths — the kind of bug that’s nearly invisible until it bites you.

Daily Observability Report Artifact Fetching

PR #40705 ensures the daily-observability-report workflow explicitly requests agent and detection artifact sets during log fetches. Without this, report generation could silently proceed without the required telemetry inputs, producing incomplete or noop outcomes.

Internals: FNV-1a Heredoc Delimiters

PR #40696 replaces SHA-256 with FNV-1a for heredoc delimiter generation. FNV-1a is dramatically faster for this use case — heredoc delimiters don’t need cryptographic-strength hashing, and the switch reduces overhead in the compiler’s string-processing path.

Token Optimization

PR #40695 reduces ambient prompt surface in high-traffic workflows. Trimming unnecessary context from the initial system prompt means fewer tokens on every invocation — the savings add up quickly when a workflow runs hundreds of times a day.

Agent of the Week: delight

Your repository’s resident UX guardian — scans documentation, CLI help text, workflow messages, and validation code for clarity, professionalism, and usability gaps, filing targeted single-file improvement tasks when it finds something worth fixing.

delight ran three times in the past 30 days (June 18, 19, and earlier in June), and all three runs completed successfully and stayed entirely read-only — meaning it reviewed the codebase and came away with nothing to file. For a workflow whose whole job is finding UX rough edges, that’s a quiet kind of compliment to the team. Each run, it randomly samples 1–2 documentation files, 1–2 CLI commands, 1–2 workflow message configurations, and 1 validation file, then evaluates them against five enterprise UX design principles: clarity, professional communication, efficiency, trust, and documentation quality.

On the rare occasions when it does find something worth flagging, it files a GitHub issue labeled both delight and cookie — because apparently good UX comes with cookies. It’s capped at 2 issues per run so it never floods your backlog, and it keeps a rolling memory of past findings to avoid flagging the same thing twice.

Usage tip: Run delight in any repo where user-facing quality matters — its single-file task constraint means every improvement it suggests is scoped, reviewable, and completable in an afternoon.

→ View the workflow on GitHub

Try It Out

Pull the latest CLI build to get the compiler performance fix, the new deferinloop linter, and all this week’s reliability improvements. As always, feedback and contributions are welcome at github/gh-aw.

Weekly Update – June 15, 2026

Mon, 15 Jun 2026 00:00:00 GMT

No releases this week — but the merge queue more than made up for it. Over 50 pull requests landed in github/gh-aw between June 9 and June 15, touching everything from Go reliability to docs, linters, and cost optimization. Here’s the highlights.

Reliability: Eliminating `time.After` Timer Leaks

PR #39188 landed one of the most satisfying fixes of the week: every looped time.After call in the CLI was replaced with a properly cancelled timer, and a new timeafterleak Go linter was wired into CI to keep it that way. In tight loops, time.After creates a new timer on every iteration without ever cleaning up the old ones — a slow drip of leaked goroutines. Now that drip is plugged, and the linter makes sure it stays that way.

New Linters: `errorfwrapv` and `timeafterleak`

Two new Go analysis linters shipped this week:

timeafterleak — flags time.After inside for+select loops where the timer would never be cancelled.
errorfwrapv — flags fmt.Errorf calls that use %v to wrap errors instead of %w, ensuring errors stay unwrappable through the call stack.

Both linters were auto-generated by the linter-miner workflow and are now enforced in CI.

Max Patch Size Increased to 4 MB

PR #39118 raises the default max-patch-size from 1 MB to 4 MB and improves the error message when a patch exceeds the limit. If your workflows were running into patch-size rejections on larger changesets, you’ll want to pull in the latest CLI — this headroom matters for repos with big generated files.

Cross-Repo `safe-outputs` Dispatch Allowlists

PR #39080 adds support for cross-repo dispatch-workflow allowlists in safe-outputs. You can now configure which repositories are allowed to trigger a dispatch-workflow safe output, giving teams fine-grained control over cross-repo automation boundaries.

Better Failure Diagnostics

Two PRs improve what you see when workflows fail:

#39122: Failure issues now include the last 5 tool calls when a tool denial triggers — so instead of “tool was denied,” you get the full context of what the agent was trying to do.
#39069: When the AI credits guardrail fires, failure issues now include an “Optimize token consumption” section with concrete suggestions for reducing costs.

Docs: Anthropic WIF and Experiments

#39241: Anthropic Workload Identity Federation (WIF) is now documented as a first-class Claude authentication option — no more hunting through PRs to figure out how to set it up.
#39226: The experiments docs were expanded with concrete examples covering custom models, sub-agents, and sub-skills.

Token / Cost Optimizations

Several PRs this week focused on reducing unnecessary token consumption:

#39280: Reduced first-request token overhead in smoke-copilot and test-quality-sentinel by trimming ambient context.
#39157: Reduced ambient-context payload across daily and PR workflows by sharing prompt imports more efficiently.

Agent of the Week: aw-failure-investigator

Your tireless overnight watchman — scans every workflow run in the repository, diagnoses root causes, and files structured GitHub issues before you’ve had your morning coffee.

aw-failure-investigator ran three times in the past week (it’s on a 6-hour schedule — it never really sleeps), consuming over 4.7 million tokens and 60 turns across those runs. In its most recent run on June 15 at 1:38 AM, it filed two P1/P2 issues: one alerting that the Daily Model Inventory Checker had been 100% broken for six consecutive days due to a session.idle 60-second timeout exhausting all retry attempts, and another flagging that both Azure OpenAI smoke variants were false-failing in lockstep due to Azure 429 throttling. Earlier in the week it also identified that Code Simplifier was silently hitting the api-proxy invocation cap (50/50 LLM calls), causing 100% failure rate with no existing tracking issue.

It ran its June 14 morning investigation in 16.6 minutes, used 1.8M tokens, and still filed 3 detailed issues — including one that caught a failure the team hadn’t noticed yet. Impressive dedication for an agent that technically has no idea what time it is.

Usage tip: Deploy aw-failure-investigator in any repo with multiple scheduled workflows — catching silent regressions at 2 AM beats discovering them at the next sprint review.

→ View the workflow on GitHub

Try It Out

All of this week’s improvements ship with the latest CLI build. Pull the newest version and explore the expanded patch-size headroom, the new linters, and the improved failure diagnostics. As always, contributions are welcome at github/gh-aw.

Effective Tokens replaced by AI Credits

Mon, 08 Jun 2026 00:00:00 GMT

In the latest gh-aw build, Effective Tokens (ET) have been replaced by AI Credits (AIC) as the primary spend metric.

This change reflects GitHub Copilot billing and models.dev pricing. It makes spend tracking directly aligned to monetary cost instead of a normalized token proxy.

What this means in practice

gh aw audit and gh aw logs report AI Credits as the primary spend metric.
Effective Tokens are deprecated in documentation and should be treated as legacy compatibility output.
Cost reporting and budget discussions should use AIC values.

For repositories that need automatic workflow updates, run:

gh aw fix --write

Metric reference

AI Credits (AIC): primary spend metric (1 AIC = $0.01 USD)
Effective Tokens (ET): deprecated legacy metric

Where to read more

Agent of the Day – June 2, 2026

Tue, 02 Jun 2026 00:00:00 GMT

Agent of the Day – June 2, 2026: The Data Detective

You know that feeling when a bill arrives and it’s higher than you expected — and the line items are all vague? That’s what staring at aggregate AI token consumption looks like without good tooling. The number goes up, the curve bends, and everyone shrugs. Was it a new workflow? A prompt gone feral? A perfectly normal Monday?

That’s the exact problem Scout was built for.

Agent of the Day: Scout

Scout is gh-aw’s on-demand research agent — a workflow you invoke with a question and come back to with an answer. It doesn’t file PRs or leave comments as part of a pipeline. It reads, reasons, and reports, turning an open-ended research prompt into structured evidence a team can actually act on.

On May 31, 2026 (run #26709587451), Scout received a deceptively simple prompt on issue #36100: investigate token usage trends from the agentic-token-audit and agentic-token-optimizer workflows across April and May.

Eight turns and 8.1 minutes later, it had the answer — and it wasn’t pretty.

What Scout Found

The headline: daily token consumption in gh-aw nearly doubled over two months, peaking at 138 million tokens on May 29 — the highest single day in the entire dataset.

Window	Avg tokens/day	Avg action-min/day
April 2026 (21 days)	~80.1M	~713
Early May (days 1–5)	~62.1M	—
Late May (days 20–29)	~101.8M	~900

Run counts stayed nearly flat the whole time — capped near 100/day by the collector’s limit. More runs weren’t the culprit. The growth was coming from within each run.

Scout traced it to two compounding forces. First, heavy-hitter workflows: the May 29 spike was dominated by PR Sous Chef (15.7M tokens across 5 runs, averaging ~186 turns per run), Safe Output Health Monitor (8.7M, single run), and Go Logger Enhancement (8.5M). Token variance tracked workflow mix and turn count almost exactly. Second, catalog growth: ~111 new agentic workflow .md files were added between April and May, pushing the repository to over 237 workflows. More workflows meant more scheduled runners pulling heavier daily reporters and analyzers into the mix.

There’s a silver lining. The agentic-token-optimizer workflow is doing its job — flagging concrete savings targets and driving commits. After Scout’s predecessor run flagged go-logger at 1.7M tokens per run on May 31, commit #36088 (“Trim go-logger workflow prompt and validation overhead”) landed quickly. The feedback loop works.

The gap is velocity: new workflows are arriving faster than optimizations land, so the net curve still bends upward.

How Scout Works

What makes this run compelling isn’t just the findings — it’s how Scout approached the problem. It used 37 distinct tool types across 8 turns, drawing on Tavily’s research suite (search, crawl, extract, map, and research) to pull historical snapshot data and cross-reference it against repository commits. It made 61 network requests with zero firewall blocks, querying the memory/token-audit branch for the daily snapshot history and reconciling gaps in the mid-May data (several dates had empty downloads from API rate-limit failures during collection).

The result was a structured research report posted directly to issue #36100, complete with a data table, a trend attribution section, caveats about data quality during the blind-spot window (May 6–19), and concrete recommendations — all in a single comment.

No pipeline. No scaffolding. Just: “here’s a hard question” → “here’s a rigorous answer.”

Why This Matters

Scout is a good reminder that not every agent needs to do something to be valuable. Some of the highest-leverage work in a complex system is the work of seeing clearly — quantifying what’s happening, attributing root causes, and giving a team a shared picture to reason from. Without that, optimization work is guesswork.

When your token bill doubles in six weeks, you want a Scout.

Want to run your own research agent or explore the full gh-aw workflow catalog? Check out the project at github.com/github/gh-aw.

Agent of the Day – June 1, 2026

Mon, 01 Jun 2026 00:00:00 GMT

Agent of the Day – June 1, 2026: The Red Team That Never Sleeps

Security scanning is easy to deprioritize. It’s invisible when it works, painful when it doesn’t, and nobody schedules it at 11:47 PM on a Sunday. That’s exactly why we automated it.

Meet the Daily Security Red Team Agent — a Claude-powered workflow that runs nightly against actions/setup/js and actions/setup/sh, looking for the things no one wants to find: backdoors, secret leaks, destructive operations, and supply-chain compromise. Last night’s run (#123, 2026-05-31T23:47:47Z) came back clean. That’s the good news. The more interesting story is what it took to get there.

What the Agent Actually Does

In 16 agentic turns over about six minutes, the agent unshallowed the repository to 12,465 commits and scanned 717 files — 379 in production scope — using bash as its forensic workhorse. It called bash 14 times: 12 directory-scan passes, two cache reads to pull context from prior runs, and one safe-output call to log its findings.

Twelve candidates came up for review. All twelve were dismissed. The agent’s logged rationale is worth reading in full, because it shows exactly the kind of reasoning you want from a security scanner:

“eval/exec calls are git/regex operations, base64 is GitHub API content decoding, rm -rf ops are workspace-scoped or credential cleanup, IP 172.30.0.1 is the documented Docker/AWF gateway, external URLs are docs/spec/placeholders, installers verify SHA256 checksums, and git tokens use the secure extraheader pattern with no secret logging.”

That’s not hand-waving. Each dismissal maps to a specific artifact class with a specific justification. The one item that didn’t get a full pass: a low-severity pre-existing observation, already in cache, about an antigravity installer that soft-skips checksum verification on HTTP 404. Noted, tracked, not new.

No issues were created this run. The agent is configured to open up to five GitHub issues per run, labeled security, red-team, prefixed with [SECURITY]. Strict mode means it won’t fabricate urgency. If it doesn’t find something real, it files nothing.

The Experiment Running Underneath

Here’s the part that makes this more than just a nightly cron job dressed up in AI. Since May 12, the workflow has been running an A/B experiment (issue #31673) comparing two analysis techniques: single_pass versus iterative. The experiment is tracking false-positive rates across both variants to figure out which approach surfaces real issues without drowning engineers in noise.

Last night’s run used the full-comprehensive technique variant. That matters because the approach shapes how the agent allocates its 1,076,688 tokens across 16 turns — whether it commits to a single deep pass or revisits candidates in multiple rounds. Understanding which technique produces better signal is precisely the kind of question you can only answer by running both and measuring.

The agent’s own behavior fingerprint classified this run as exploratory — methodical, wide-coverage, following leads rather than checking predetermined boxes. That fits the full-comprehensive profile. It also means roughly half the turns were data-gathering that could, in principle, move to deterministic pre-processing steps. That’s not a criticism; it’s a roadmap.

Why This Matters

Actions setup scripts are high-value targets. They run early in CI pipelines, often with elevated permissions, before most other controls are in place. A compromised installer or a leaked token in that path is a bad day for everyone downstream.

Running a human red-team review at that depth every night isn’t realistic. Running a token-heavy AI agent that unshallows 12,000+ commits and reasons through eval patterns at 11 PM on a Sunday, every Sunday? That’s exactly the kind of work that should be automated — not because it’s easy, but because the alternative is doing it inconsistently or not at all.

The workflow logged a clean bill of health. The experiment is generating data. The cache carries forward observations across runs so context doesn’t reset to zero every night. That’s an agent doing its job.

If you want to see how the workflow is structured, run your own experiments, or understand how cache-memory persistence works across agentic runs, the full source is at github/gh-aw. The red team never sleeps — but it does file issues when it finds something.

Agent of the Day – June 1, 2026

Mon, 01 Jun 2026 00:00:00 GMT

Agent of the Day: Architecture Guardian

Architectural drift is quiet and cumulative. A file grows past 600 lines. A function absorbs one more responsibility. An import cycle sneaks in between two packages that “just need to share a little logic.” None of it trips a CI gate, no test turns red, and six months later a new engineer opens that directory and wonders how it got this bad. The Architecture Guardian workflow exists precisely to interrupt that pattern before it becomes load-bearing.

What It Does

The Architecture Guardian runs on a weekday schedule, firing each afternoon around 14:00 UTC. It pulls the last 24 hours of commits, walks every changed Go and JavaScript file, and applies a tiered set of structural checks:

File size: files over 500 lines generate a warning; over 1,000 lines, a blocker.
Function length: any function exceeding 80 lines is flagged.
Export count: more than 10 exports from a single file draws scrutiny.
Import cycles: the full dependency graph of changed packages is traced for cycles.

When violations surface, the workflow doesn’t just log and move on. It opens a GitHub issue labeled architecture, automated-analysis, and cookie, assigned directly to Copilot for triage. The issue is the artifact — something a team can discuss, link to a PR, close when remediated.

The engine is GitHub Copilot, running as an agentic workflow defined in architecture-guardian.md. No bash scripts wrapping static analysis tools, no bespoke CI job to maintain. The analysis logic, thresholds, and issue-creation behavior all live in a single, readable workflow spec.

The June 1 Run

Run 26766995181 completed on June 1, 2026 at 16:18 UTC, five minutes and forty seconds after it started. The agent worked through three turns with claude-sonnet-4.6 via GitHub Copilot, made 10 GitHub API calls, and consumed 125,356 tokens — a number that looks large until you factor in the effective token count of 1,206,982 once prompt caching is included. Caching is doing real work here.

The verdict: no violations. Every changed file over the past 24 hours fell within the configured thresholds. The agent’s own summary put it plainly — “0 files analyzed, no import cycles detected.” Nothing to open, nothing to assign.

That outcome is worth pausing on. A clean run isn’t a null result; it’s confirmation. The codebase was touched, the guardian looked, and the boundaries held. Knowing that with specificity — on a schedule, with a receipt — is materially different from assuming it because nothing has caught fire yet.

Why the Thresholds Matter

The 500-line warning and 1,000-line blocker aren’t arbitrary. Files in that range have a documented tendency to accumulate mixed responsibilities: they’re long because they’re doing too many things, not because the domain is genuinely complex. The 80-line function limit enforces a similar discipline. It’s not a style preference; it’s a forcing function for decomposition.

Export counts above 10 are a softer signal — a package with 15 exports might be perfectly well-structured — but they surface files worth a second look. Import cycles are harder: they indicate a structural coupling that can’t be resolved without a real refactor, and they compound over time.

The Architecture Guardian makes these checks automatic and visible without requiring anyone to remember to run a linter or build a policy around code review checklists. The standards are encoded in the workflow. The workflow runs whether or not anyone’s thinking about it.

Grounded Takeaways

A few things worth noting if you’re thinking about adapting this pattern for your own team:

Scheduling matters. A daily check at 14:00 UTC catches violations before they’re a day old. Violations that linger for a week become rationalizations.

Issue creation is the accountability loop. Logging a warning to stdout is easy to ignore. An open issue is harder to lose, links to the violating commit, and can be closed with a reference to the fixing PR. That chain is the point.

Clean runs are data. The June 1 run found nothing. That’s not a failure of the workflow — it’s the workflow confirming steady-state health. Over time, a history of clean runs punctuated by occasional issues tells you something real about your team’s structural discipline.

Token efficiency scales. 1.2 million effective tokens for a daily architectural scan, amortized across a codebase’s active lifetime, is not expensive. The cost of a missed import cycle or a 2,000-line God file is.

The Architecture Guardian is one of the workflows available in github/gh-aw. If your team is dealing with structural drift — or wants to make sure it never starts — the repository has the workflow definitions, the engine configuration, and the patterns to adapt it to your thresholds and language stack.

Weekly Update – June 1, 2026

Mon, 01 Jun 2026 00:00:00 GMT

It’s been a busy week in github/gh-aw! Five releases landed between May 28 and May 31, capped off by v0.77.4 — one of the biggest releases in recent memory. Here’s everything that shipped.

Release: v0.77.4

v0.77.4 published on May 31st and packs in a ton of new capability.

What’s New

Anthropic WIF Authentication (#35939): Claude-engine workflows can now authenticate via Workload Identity Federation. No more long-lived API key secrets stored in your repo — WIF handles it securely.
copilot-sdk Engine (#35936): A new engine: copilot-sdk frontmatter option gives workflows direct access to the Copilot SDK runtime, opening up new integration patterns.
aw.yml Manifest: Includes, Skills & Agents (#35778): Your repository manifest now supports includes, skills, and agents keys so you can compose and share workflow components across repos.
Per-Workflow 24-Hour Effective-Token Guardrail (#36042): A configurable token guardrail prevents runaway agent costs with enterprise-grade defaults and handy ET shorthand support.
search_commits in GitHub MCP Search Toolset (#36115): Agents can now search commits directly via the GitHub MCP search toolset.
New Skills: copilot-review and go-codemod (#36111, #36034): Two new skills help agents plan and address PR review feedback, and implement Go codemods for the gh aw fix command.

Notable Fixes

Prefer toolcache Copilot CLI (#35992): Workflows now use the Actions toolcache copy of the Copilot CLI before downloading a release — faster setup for everyone.
Reusable workflow timeout (#36107): timeout-minutes is now correctly passed through reusable workflow callers.
Threat-detection hardening (#36113): Missing prompt artifacts no longer block safe-output execution.
on.needs YAML strip (#35965): Processed on.needs keys are stripped from emitted YAML, preventing invalid workflow syntax.

Release: v0.77.3

v0.77.3 on May 29th brought sandbox improvements and better initialization:

authHeader in sandbox agent targets (#35694): You can now specify custom authentication headers directly in sandbox.agent.targets frontmatter.
gh aw init creates the Agentic Workflows custom agent (#35773): Running gh aw init now scaffolds a GitHub Copilot custom agent for Agentic Workflows right out of the box.
Stricter schema validation for workflow_call/workflow_dispatch (#35788): Unknown input keys are now rejected at compile time.

Notable Merged PRs This Week

Add project UTC offset support for rendered timestamps — Timestamps and expiration messages now render correctly for teams in non-UTC time zones.
Optimize api-consumption-report with inline small-model sub-agents — The API consumption report workflow is now faster and more efficient thanks to inline sub-agents.
Add structured diagnostics to the daily workflow ET guardrail — The effective-token guardrail now emits structured logs with a stable [daily-workflow-et] prefix, making debugging much easier.
Enable close_discussion safe output in Daily Regulatory workflow — The regulatory compliance workflow can now close discussions as part of its cycle.

Agent of the Week: api-consumption-report

The bean counter who never sleeps — tracks every GitHub API call your workflows make and publishes a detailed report so you know exactly where your rate-limit quota is going.

This week api-consumption-report analyzed 95 workflow runs across the repository (58 successes, 37 failures — it doesn’t sugarcoat the numbers), tallied up 10,619 GitHub REST API calls in a single day, and generated a full trend chart showing that API usage spiked to ~80K calls on May 20th before settling back down. It also uploaded five charts as release assets — a trend line, a heatmap, a per-workflow breakdown, a “burners” donut chart, and a workflow-level trend — then published the whole package as a GitHub Discussion for everyone to browse.

Hilariously, in one of its recent runs it completed in under 2 minutes with zero token usage and exactly one GitHub API call. Turns out that was the run where the cache hadn’t warmed yet — it took a look around, shrugged, and went home early.

Usage tip: Schedule this workflow weekly to catch runaway API consumption before you hit rate limits — the per-workflow breakdown makes it easy to spot which agent is hogging the quota.

→ View the workflow on GitHub

Try It Out

Upgrade to v0.77.4 today and explore the new copilot-sdk engine and WIF authentication for Claude. As always, feedback and contributions are welcome at github/gh-aw.

Agent of the Day – May 29, 2026

Fri, 29 May 2026 00:00:00 GMT

By the time an issue makes it into your backlog, someone already spent time writing it. The least you can do is make sure it gets read by the right person quickly. In practice, that rarely happens — unlabeled issues pile up, the search experience degrades, and the right engineer finds out about a relevant bug two sprints too late. Labeling sounds simple. Doing it consistently, at scale, without burning anyone’s afternoon, is the actual challenge.

That’s exactly the problem the Auto-Triage Issues workflow in gh-aw was built to solve.

Agent of the Day

Workflow: Auto-Triage Issues
Engine: GitHub Copilot (gpt-5-mini)
Run: #26640355375 — May 29, 2026, 13:34 UTC
Result: ✓ SUCCESS

What It Does

Auto-Triage Issues runs on a schedule — several times a day — and also fires on issues events. Each pass, it reads through unlabeled GitHub issues, reasons about their content, and applies labels with a stated confidence level and rationale. No human in the loop. No queue to drain manually.

The agent runs behind an enabled squid-proxy firewall, with outbound access scoped to github.com and approved defaults. That constraint is intentional: triage doesn’t need the open internet, and limiting the blast radius of any agent is good practice regardless of what it’s doing.

Today’s midday run is a useful case study in how the workflow behaves under varying load.

The Morning Run vs. The Midday Run

The 07:45 UTC pass (run #26625003469) was a light one: 7 turns, finished in 5 minutes. A handful of issues to consider, quick classification, done. That’s what a steady-state workload looks like.

By 13:34 UTC, the picture was different. The agent completed 28 turns over 10 minutes — four times the conversational depth, twice the elapsed time. Same workflow, same model, same success result. The difference was the volume and complexity of what was waiting in the queue.

This matters because it shows the system isn’t just running a fixed script. The agent works through each issue, reasons about it, and the turn count reflects real cognitive work being done. A heavier inbox produces a longer run, not a failure or a time-out.

What Got Triaged Today

Two issues received labels during the midday run:

Issue	Labels Applied	Rationale
#35708	`automation`	”Automated triage report with no bug/feature signal”
#34915	`documentation`, `automation`	”Automated documentation quality report generated by automation; content is documentation-focused and workflow-generated”

Both calls were high-confidence. Issue #34915 is a good example of the multi-label path: the agent identified that the issue was both workflow-generated and documentation-focused, and applied both labels rather than forcing a single category. That kind of nuanced classification is where static regex-based approaches tend to fall short.

The Discussion Output

At the end of each run, the workflow doesn’t just apply labels and exit quietly. It creates — or updates — a GitHub Discussion titled [Auto-Triage Report] 2026-05-29, containing a Markdown table that summarizes every issue it classified: the issue number, the labels applied, confidence level, and the agent’s reasoning.

That report serves two purposes. First, it’s auditable — a reviewer can open the Discussion and see exactly what the agent decided and why, without digging through logs. Second, it creates a natural place for human override: if a classification looks wrong, the context is right there to inform a correction.

Transparency in automated triage isn’t optional. Reviewers need to trust the output before they’ll stop second-guessing it.

Why gpt-5-mini

The model choice here is deliberate. gpt-5-mini is fast and cost-effective for classification tasks where the signal is textual and the label set is bounded. You don’t need a heavyweight model to tell the difference between a documentation report and a bug report. Reserving larger models for tasks that actually need them — planning, synthesis, code generation — keeps the system efficient across a full day of scheduled runs.

Try It Yourself

If your repository is drowning in unlabeled issues, Auto-Triage is a pattern worth adopting. The workflow lives in github/gh-aw, alongside the rest of the agentic workflow library. The firewall configuration, the Discussion report pattern, and the label confidence output are all ready to fork and adapt.

Triage shouldn’t be a task anyone has to remember to do. It should just happen — correctly, consistently, and with a paper trail.

Agent of the Day – May 28, 2026

Thu, 28 May 2026 00:00:00 GMT

Every codebase accumulates sediment. A helper function that made sense six months ago. A wrapper that lost its reason to exist after a refactor. Nobody deletes it on purpose — it just lingers. In Go, that lingering costs you: extra surface area to maintain, test coverage for code that does nothing new, and cognitive overhead for every engineer who reads the file.

The Dead Code Removal Agent is a scheduled GitHub Actions workflow that runs daily on the gh-aw repository. Its job is simple: find unused code, verify nothing breaks, and open a pull request. No human intervention required until review time.

Agent of the Day

Run #100 — A Quiet Milestone

On May 27, 2026, the agent completed run #100. Not a fanfare moment — just another daily run doing exactly what it was built to do. It finished in 11.4 minutes across 5 turns, consumed 14.6M effective tokens, and used 12 GitHub Actions minutes.

The target this time was NewValidationErrorWithLocation in pkg/workflow/workflow_errors.go. The function was a constructor wrapper around WorkflowValidationError — originally a convenience, but over time it became redundant as callers could initialize the struct directly. The agent identified it, confirmed it had no remaining callers, and started working.

The tool call sequence tells the story cleanly: one Install, eight Check passes, five Reads, three Views, four Edits, a Find, a Verify, a Format, two Runs, two Creates, an Update, and a Vet. That’s methodical, not mechanical. The agent didn’t just delete the function — it removed the corresponding TestNewValidationErrorWithLocation test from pkg/workflow/error_helpers_test.go and updated compiler_error_formatting_test.go to use direct WorkflowValidationError struct initialization instead.

Verification was thorough. Before touching the PR, the agent ran go build ./..., go vet ./..., go vet -tags=integration ./..., and make fmt. Everything passed. The resulting PR — “chore: remove dead functions — 1 function removed” on branch chore/remove-dead-code-20260527 — arrived clean, with no lint issues and a test suite that still compiles.

What Five Runs Look Like

Zoom out a week and the picture gets more interesting. Across five runs in the last seven days, the agent logged:

35.5 minutes total duration
38.9M effective tokens
38 GitHub Actions minutes
21 turns across all five runs
5 out of 5 high-confidence episodes

Run classification across that window: two normal runs, one risky, one failure, one in-progress. The failure and the risky classification matter as much as the successes. The agent doesn’t always find something safe to remove, and when it can’t complete cleanly, it doesn’t force a PR. That restraint is a feature, not a gap.

Why Automation Fits This Problem

Dead code removal is well-suited to an agent for a specific reason: the feedback loop is entirely mechanical. Does it build? Does go vet pass? Does the test suite still run? Those questions have definitive answers. The agent never has to speculate about intent — it just has to be rigorous about verification, which it is.

The harder editorial question — should this code be removed — is answered by the PR review. The agent does the investigation and the grunt work. Engineers do the judgment call. That division feels right.

There’s also something useful about the daily cadence. A function doesn’t become dead overnight. But catching it the morning after the last caller disappears, rather than six months later during a refactor, is the difference between a one-line deletion and an archaeology project.

Get Involved

If you’re curious about how the Dead Code Removal Agent is built, or if you want to run something similar against your own Go codebase, the workflow lives at github/gh-aw. The patterns here — schedule-triggered agents, structured verification steps, PR-as-output — are composable. Start there.

Run #100 was just another Tuesday. That’s the point.

Agent of the Day – May 27, 2026

Wed, 27 May 2026 00:00:00 GMT

Every day, 236 agentic workflows run inside the gh-aw repository. Most complete quietly. A few fail in patterns worth tracking. And once a week, one workflow reads the entire fleet, scores it, and writes up what it found. That workflow is the Agent Performance Analyzer, and its run on May 27, 2026 produced the clearest signal in months.

Agent of the Day: Agent Performance Analyzer — Meta-Orchestrator

The agent-performance-analyzer is not a workflow that builds features or merges PRs. Its job is to watch everything else. On a daily schedule, it fans out across the full fleet of 236 workflows, scores each agent group across three dimensions — quality (0–100), effectiveness (0–100), and ecosystem health (0–100) — and surfaces what the aggregate data says about systemic health. Think of it as a standing post-incident review that runs without anyone needing to call one.

Run #26515287616, logged on May 27, ran for 10.7 minutes and processed 12.2 million effective tokens. Those numbers matter because they reflect how much context the analyzer actually reads — audit logs, PR outcomes, failure histories, discussion threads — before rendering a score. This is not a lightweight health check.

The headline number from this week’s pass: ecosystem health hit 90/100, up 20 points from the prior week. That is the largest single-week jump in the recorded history of this metric. It is also a number that demands interpretation, not celebration. A 20-point move in one week usually means either the fleet genuinely improved, or something was suppressing the score before and is now resolved. The weekly Discussion #35220 breaks down the contributing factors — most of the lift came from copilot-swe-agent merge rate recovery, which landed at 67% week-over-week, up 6 percentage points, with 6 merges on May 27 alone. Merge rate as a proxy for workflow effectiveness is imperfect, but 67% across a fleet this size is a meaningful signal.

The top performers bear out that story. Lint Monster scored 90/100 on quality and 85/100 on effectiveness — consistent, expected, unglamorous. copilot-swe-agent followed at 88/100 quality and 84/100 effectiveness. spec-enforcer/extractor went 3-for-3 on merges this week, a 100% merge rate on a small but non-trivial sample. These are the parts of the fleet holding their line.

Quality, though, is flat. 74/100 for the fourth consecutive week. A plateau at week four is no longer noise. The analyzer flagged this directly: without intervention, the quality score will not self-correct. The fleet is not degrading, but it is not improving either, and in a system that runs daily, stasis accumulates.

What the Analyzer Filed This Week

The more operationally significant output from this run was not the Discussion — it was issue #35219. The analyzer detected a Copilot CLI execution failure pattern affecting the Daily News and Daily Issues Report workflows across five or more consecutive days at a 100% failure rate. A workflow failing once is noise. Failing every day for a week is infrastructure. The issue was filed automatically based on threshold logic baked into the analyzer’s scoring criteria. No human had to notice the pattern.

Three other systemic issues surfaced in Discussion #35220. A safe-outputs permission regression is blocking three or more agent groups and has been classified P1. A CGO/CJS build regression running at 37% failure rate has now exceeded 90 days without resolution — that is a P0 by any reasonable SLO definition. And 87 of the fleet’s 236 workflows show no recent runs at all, which makes them deprecation candidates pending owner review. The firewall processed 113 requests during this period and blocked 30 of them — a 27% block rate — which is consistent with prior weeks but warrants monitoring if the trend climbs.

The value of a meta-orchestrator is not that it prevents incidents. It is that it shortens the time between an incident beginning and someone with context knowing about it. Five consecutive days of 100% failure on two named workflows, with an auto-filed issue linking directly to the evidence, is a materially better outcome than a developer noticing something is off on day seven.

The work of keeping 236 workflows healthy is mostly invisible until something breaks. The Agent Performance Analyzer makes that work legible — in scores, in filed issues, in a weekly Discussion that records what the fleet looked like at a point in time. If you want to follow along, the full weekly report is in Discussion #35220, and the project lives at github/gh-aw.

Agent of the Day – May 26, 2026

Tue, 26 May 2026 00:00:00 GMT

Every morning someone at GitHub opens their laptop and wonders: how well did the coding agents do yesterday? Did they ship? Did they stall? Did they create more work than they saved? These questions used to require manual spelunking through dashboards, cross-referencing merged PRs with author names, and guessing at patterns from vibes alone.

Not anymore.

Agent of the Day: Copilot Agent PR Analysis

The Copilot Agent PR Analysis workflow runs daily at 6pm UTC with a single mandate: understand how GitHub’s own coding agents are performing in the wild. It watches copilot-swe-agent-authored pull requests, tracks their lifecycle from open to merge (or close), and surfaces patterns that would otherwise vanish into the noise of a busy repository.

Run 26415065259 on May 25th tells the story. Six minutes. Nineteen agent turns. Nearly a million tokens processed. And at the end, a GitHub Discussion summarizing everything the agents accomplished in the last 24 hours—merge rates, review turnaround, file change distributions, the works.

What makes this run interesting isn’t just the output—it’s the mechanics underneath. The workflow starts by reading pre-fetched PR data from /tmp/gh-aw/agent/pr-data/copilot-prs.json, a file populated by an earlier step that batches GitHub API calls. This matters because API rate limits are a real constraint when you’re analyzing dozens of PRs daily. By front-loading the data fetch, the Claude Opus 4.7 model can focus on analysis rather than pagination logistics.

From there, the agent orchestrates across 16 different tool types. github-list_pull_requests and github-search_pull_requests pull in the raw data. github-get_file_contents adds context when the agent needs to understand what a PR actually changed. push_repo_memory persists metrics for trend analysis—because spotting a single bad day matters less than spotting a three-week decline. And create_discussion posts the findings where the team can actually see them.

The token economics tell their own story. Of the 947,148 tokens consumed, over 3 million effective tokens came from cache reads—a 63% hit rate. That’s not an accident. The workflow’s prompt structure and tool imports are designed to maximize cache reuse across runs. At $1.53 per execution, this is the kind of analysis that would cost ten times more if you rebuilt context from scratch each day.

Nineteen turns might sound like a lot, but the average inter-turn time of 19.8 seconds reveals something important: this agent is thinking, not thrashing. It’s making deliberate tool calls, waiting for responses, incorporating results, and planning next steps. The turn count reflects adaptive planning—the kind of reasoning that adjusts when it finds fewer PRs than expected or more activity in an unexpected repository corner.

PR #34947, merged just one day after this run, shows the feedback loop in action. Titled “Normalize copilot-session-insights discussion output hierarchy and disclosure,” it refined how the analysis gets presented—making the daily summaries easier to scan and the trend data more accessible. The workflow’s own output informed improvements to the workflow itself.

This is what continuous observability looks like for AI systems. Traditional software gets monitored with APM tools, error rates, and latency percentiles. But when your “software” is an autonomous agent making judgment calls about code, you need a different kind of visibility. You need to know: are the agents getting better at writing tests? Are they over-indexing on certain file types? Are their PRs sitting in review limbo, or are humans accepting them quickly?

The Copilot Agent PR Analysis workflow answers these questions daily, automatically, without anyone remembering to ask.

Curious about building workflows that watch your workflows? Explore the full gh-aw project at github/gh-aw—where agentic automation meets operational insight.

Agent of the Day – May 25, 2026

Mon, 25 May 2026 00:00:00 GMT

Some days the agent has nothing to report, and that’s exactly the point. I pulled up run 26407385057 this morning — 3.8 minutes, clean sweep. No violations. The Architecture Guardian looked at everything that landed in the last 24 hours and came back with a simple verdict: all changed files are within configured thresholds. In a codebase that moves this fast, that outcome doesn’t happen by accident.

Agent of the Day: Architecture Guardian

The Architecture Guardian runs every weekday around 14:00 UTC. Its job is unglamorous and essential: scan every .go, .js, .cjs, and .mjs file touched in the last 24 hours (tests and vendor excluded) and ask whether the code is still structurally sound. It’s the kind of review that humans intend to do and quietly skip.

The mechanics are deliberate. A bash pre-step calls git log --since="24 hours ago" to build the file list. From there it computes line counts, function sizes, and export counts for each file, then runs go list ./... to catch import cycles before they calcify. Everything lands in /tmp/gh-aw/agent/arch-metrics.json. A lightweight sub-agent — violation-classifier, running on a small model — reads that JSON and applies a three-tier severity ladder:

BLOCKER — files exceeding 1,000 lines or any import cycle
! WARNING — files over 500 lines or functions over 80 lines
INFO — files exporting more than 10 identifiers

If it finds something, it opens a GitHub issue with a structured report, tagged architecture, automated-analysis, and cookie. If not, it calls noop and gets out of the way. There’s also a guard against noise: a shared skip-if-issue-open.md import prevents the agent from filing duplicate issues when a violation is already being tracked.

What stands out about today’s run isn’t the clean result — it’s the efficiency behind it. 121,425 input tokens processed, but 75,961 of those came from cache reads. That’s roughly 63% cache hit rate, which means the agent isn’t re-reading static context on every run; it’s built to reuse it. Total AI turns: 3. GitHub API calls: 4. The whole thing resolved in under 4 minutes with 307 output tokens — barely a paragraph’s worth of text to confirm the codebase is healthy.

That ratio matters. The Architecture Guardian isn’t trying to be clever. It’s trying to be cheap and reliable — the kind of automation you can run daily without flinching at the cost or the alert fatigue. Thresholds live in .architecture.yml, so teams can tune what counts as a violation without touching the workflow itself. The 2-day expiry on issues (via daily-issue-base.md) keeps the tracker clean even when something does slip through.

I’ve seen codebases where large files and tangled imports accumulate like sediment — not because anyone chose it, but because nobody had a lightweight, automatic way to notice. This workflow is that noticing mechanism. It doesn’t replace a thoughtful architecture review. It makes sure the small things don’t compound into the kind of mess that makes a real review feel hopeless.

Today it found nothing. Some days it will. Either way, it showed up.

Explore the full workflow and the rest of the gh-aw suite at github/gh-aw.

GitHub Agentic Workflows | Blog

Weekly Update – August 10, 2026

Release: v0.86.1

What’s New

Release: v0.86.0

Security & Redaction

Notable Pull Requests

Agent of the Week: PureLock

Try It Out

Weekly Update – August 3, 2026

Release Highlights

v0.84.2 — August 1

v0.84.0 and v0.84.1

Notable Pull Requests

Agent of the Week: Dead Code Removal Agent

Try It Out

Weekly Update – July 27, 2026

Releases This Week

v0.83.0 — July 22

v0.83.1 — July 23

v0.83.2 — July 24

v0.83.3 — July 25

Agent of the Week: Daily GitHub Docs SEO Optimizer

Try It Out

Weekly Update – July 20, 2026

Release: v0.82.13

! Breaking Change

What’s New

Notable Pull Requests

Agent of the Week: Avenger

Try It Out

Weekly Update – July 13, 2026

Release: v0.82.8

What’s New

Notable Pull Requests This Week

Agent of the Week: aw-failure-investigator

Try It Out

Weekly Update – July 6, 2026

Notable Pull Requests

fix(compiler): auto-add pre_activation to safe_outputs/conclusion needs

refactor(linters): consolidate AST/context helpers into internal/astutil

ambient-context: reduce copilot-agent-analysis first-request size by ~28%

Add shared prompt quality gate for plateaued agent-review workflows

fix(setup/js): numeric coercion, setOutput stringification, and async entrypoint cleanup

Agent of the Week: Weekly Issue Summary

Try It Out

Weekly Update – June 29, 2026

New: Copilot Canvas Extension for Agentic Workflows

Security: Sandbox Hardening Reaches 80%

Code Scanning Fixer: Now Covers All Severity Levels

Runtime: mcpg v0.3.32 + Firewall v0.27.13

Other Merges Worth Noting

Agent of the Week: agent-persona-explorer

Custom Linters in Practice: Sergo, Linter Miner, and LintMonster

Linter Miner keeps adding new rules

Sergo pressure-tests the linters after they land

LintMonster turns diagnostics into repository work

Why the three-workflow loop matters

Further evidence

Weekly Update – June 22, 2026

Performance: +320% Compiler Regression Fixed

New Linter: deferinloop

gh-aw-detection Rolls Out to 50% of Workflows

Reliability Fixes

JSON-RPC Error Handling

Skillet Sparse Checkout Path Typing

Daily Observability Report Artifact Fetching

Internals: FNV-1a Heredoc Delimiters

Token Optimization

Agent of the Week: delight

Try It Out

Weekly Update – June 15, 2026

Reliability: Eliminating time.After Timer Leaks

New Linters: errorfwrapv and timeafterleak

Max Patch Size Increased to 4 MB

Cross-Repo safe-outputs Dispatch Allowlists

Better Failure Diagnostics

Docs: Anthropic WIF and Experiments

Token / Cost Optimizations

Agent of the Week: aw-failure-investigator

fix(compiler): auto-add `pre_activation` to `safe_outputs`/`conclusion` needs

refactor(linters): consolidate AST/context helpers into `internal/astutil`

New Linter: `deferinloop`

`gh-aw-detection` Rolls Out to 50% of Workflows

Reliability: Eliminating `time.After` Timer Leaks

New Linters: `errorfwrapv` and `timeafterleak`

Cross-Repo `safe-outputs` Dispatch Allowlists