August 20, 2026: CodeQL update, Copilot workflow, and the latest status signals

Good morning. It is August 20, 2026, and GitHub’s clearest new signal is technical rather than flashy: CodeQL 2.26.3 shipped on August 19.

GitHub says this release improves GitHub Actions query accuracy and expands JavaScript, TypeScript, and Vue source modeling, while removing the codeql.actions.security.SelfHostedQuery module. In plain language, that means the security scanner should be better at following code paths through more modern JavaScript stacks and at reading Actions workflows more accurately. The tradeoff is that any custom query or automation that depended on the removed module may need an update. GitHub also says new CodeQL versions are automatically deployed to GitHub.com code scanning users, while future GitHub Enterprise Server support comes later and older GHES users can manually upgrade. So this is not just a library bump. It is a security-product change with a clear rollout path and a clear compatibility edge.

On the Copilot side, GitHub continues to push beyond single-chat usage and toward session-based work management. In a new Copilot app post, GitHub describes the My work pane as a place to track what is in flight, what is done, and what is next across multiple Copilot sessions. That is a company claim, not proof of adoption, but it fits the broader product direction. GitHub is trying to make Copilot act less like a one-off assistant and more like a coordination layer for several parallel tasks.

That matters because the bottleneck in agentic work is often not typing speed. It is context switching. If a developer is juggling bug fixes, a review request, and a new feature branch, the cost is in remembering what each task needs and where each one stands. GitHub’s My work pane, agent apps, and session model are all designed to reduce that coordination cost. In other words, the value shifts from writing one chunk of code faster to keeping many small tasks moving without dropping the thread. It is a subtle shift, but it is an important one for teams that run many parallel streams.

The entitlement and governance picture is also still fairly tight. GitHub docs say agent apps are in public preview, are available for all paid Copilot plans, can be started from issues, pull request comments, or the Agents UI, and require the enterprise Copilot policy to be enabled when installed in an enterprise-owned organization. GitHub’s MCP guidance says managed settings are generally available, recommends allowlists through managed-settings.json, and describes custom registries as public preview with weaker enforcement. And GitHub’s auto model selection is available with all Copilot plans, choosing models based on real-time system health and task complexity while excluding models blocked by policy or by data-residency and FedRAMP restrictions.

Put together, that means GitHub is offering more agent surface area, but the enterprise buyer still controls the perimeter. The company is expanding what Copilot can do, while keeping policy and model routing as admin-level levers.

On reliability, the status picture is broader than a single incident. GitHub’s status API shows a resolved August 18 incident affecting runner group and runner-related permissions pages, with GitHub saying a detailed root cause analysis will follow. The same feed still shows the August 17 GitHub.com incident, which touched Git Operations, Webhooks, API Requests, Issues, Pull Requests, Actions, Pages, and Copilot. The postmortem says VS Code retry behavior helped amplify Copilot Token Service traffic from 7 to 9K requests per second up to 70 to 100K requests per second.

That retry detail is the most interesting operational clue. It suggests the failure was not only about raw load. It was also about how clients reacted when the service struggled. When retries are too eager, a temporary slowdown can become a traffic storm. That is a known distributed-systems problem, but here it shows up in a product many developers use every day.

So the near-term GitHub story is not one giant launch. It is a steady tightening of the same stack: better security analysis, more agent workflow structure, more explicit enterprise controls, and a status trail that still points to retry behavior as a key reliability risk.

What to watch next: whether GitHub publishes the promised root-cause analysis for the August 18 runner-permissions incident; whether any docs update clarifies Copilot fallback behavior when a model or provider is degraded; whether agent apps or MCP governance move closer to general availability defaults; and whether GitHub adds any follow-up detail to the August 17 Copilot outage postmortem about retry limits or client-side backoff.