DEV Community

Manu Shukla
Manu Shukla

Posted on Originally published at ecorpit.com

GitHub's 21 August 2026 Copilot launch in Slack and Teams contradicts its own docs

GitHub's 21 August 2026 Copilot launch in Slack and Teams contradicts its own docs

Summary. On 21 August 2026 GitHub published two changelog entries within four minutes of each other: Copilot cloud agent in Slack, and Copilot cloud agent in Microsoft Teams. Both link to a docs page. Across those four pages GitHub gives three different answers to three questions a platform team has to settle before switching this on: which Copilot plans qualify, what a session costs, and whether the extra merge approval on agent-authored pull requests is opt-in or already running. The Slack post restricts the preview to Copilot Business and Copilot Enterprise; the Slack docs page says "all paid Copilot plans". The Teams post says sessions "consume AI credits" and that cloud sandbox usage is "billed separately"; the Slack post says usage "counts against your existing Copilot entitlements" and never mentions the second meter. Cloud sandboxes are metered at $0.000024 per compute second, $0.000003 per GiB second and $0.005 per GiB month, and the $10 monthly preview entitlement that softened those rates was, by GitHub's own wording, "available through the end of July 2026". Slack Code itself launched a day earlier, on 20 August 2026, with Anthropic, Cognition, GitHub and Vercel live.

What actually shipped, and when

Slack announced Slack Code on 20 August 2026: a channel type built for coding agents, with separate tabs for the conversation, the plan, the code diffs and a live preview. Slack says the channel archives itself when the work lands and stays searchable as an audit record, and that "Over 70% of code channels spin up and close within a single day, from idea to merged PR."

GitHub followed the next morning. The Slack entry is timestamped 21 August 2026 and describes the GitHub app for Slack bringing "the agentic capabilities of GitHub Copilot CLI and the GitHub Copilot app into Slack in public preview". The Teams entry carries the same date. Both are tagged copilot and collaboration tools on GitHub's changelog index, and both sit above the 18 August JetBrains managed-settings release.

Vercel got there first by a day. Its 20 August changelog entry, "Vercel Agent is now available in Slack code channels", describes starting a code channel to give a task its own shared Vercel Agent session.

So four vendors shipped agents into one chat surface inside 48 hours. The interesting part is not that they did it. It is that GitHub's own documentation set has not caught up with its own launch posts.

Conflict one: which plans qualify

The Slack changelog is specific and narrow:

The public preview is available to organizations on GitHub Copilot Business and GitHub Copilot Enterprise plans.

The docs page it points at is neither. Under "Who can use this feature?" it says only:

Available for all paid Copilot plans.

The Teams changelog agrees with the docs, not with the Slack post: "The public preview is available with paid GitHub Copilot plans." And the Teams docs page repeats the blanket line, "Available for all paid Copilot plans."

Three of the four pages say any paid plan. One says Business and Enterprise only. For a 40-person team on Copilot Pro+ that difference decides whether this is a Monday experiment or a procurement conversation. Until GitHub reconciles the pages, treat the narrower claim as the operative one and confirm with your account team before you promise anything internally.

Page Published Plan eligibility as written
GitHub changelog, Copilot in Slack 21 Aug 2026 "organizations on GitHub Copilot Business and GitHub Copilot Enterprise plans"
GitHub changelog, Copilot in Teams 21 Aug 2026 "available with paid GitHub Copilot plans"
GitHub Docs, cloud agent with Slack undated "Available for all paid Copilot plans"
GitHub Docs, cloud agent with Teams undated "Available for all paid Copilot plans"
Salesforce, Slack Code announcement 20 Aug 2026 Slack side "available on any Slack plan. Access to each partner agent is required"

Conflict two: the second meter nobody put in the Slack post

The Teams changelog spells the billing out in three sentences:

GitHub Copilot cloud agent sessions started in Microsoft Teams consume AI credits. For organizations, cloud agent AI credit usage is governed by usage-based billing budgets. Cloud sandbox usage is billed separately and can be controlled with a product-level or SKU-level budget.

The Slack changelog, published four minutes later about the same engine, says something different and shorter: "Usage counts against your existing Copilot entitlements and can be managed with existing Copilot cloud agent budgets." No AI credits. No second meter.

Both docs pages carry no billing statement at all. Neither page contains the words "AI credits", "premium request" or "billed" anywhere in the article body.

That matters because both surfaces run the same sandbox. The Slack docs page states the prerequisite plainly: "To use Copilot cloud agent, you must have cloud sandboxes enabled for your Copilot plan." So a Slack-started session runs in a cloud sandbox exactly like a Teams-started one, and cloud sandboxes have their own price list.

GitHub's billing page gives it. Local sandboxing "is included in the standard GitHub Copilot seat at no additional cost". Cloud sandboxing is not:

Meter What it measures Unit price (USD, Aug 2026)
Compute Time a cloud sandbox session is running $0.000024 per compute second
Memory Memory allocated while the session runs $0.000003 per GiB second
Storage Snapshot storage for stopped sessions $0.005 per GiB month

Arithmetic on GitHub's own published rates: a running sandbox costs $0.0864 an hour on the compute meter alone, plus $0.0108 per allocated GiB per hour. An eight-hour session with 4 GiB allocated is $0.69 of compute and $0.35 of memory, about $1.04 before storage. That is small per session and not small at 200 developers who have just been told they can start one by typing @GitHub in any channel.

Two further details from the billing page change the shape of that number. Memory "is measured based on the memory allocated to the session, not the memory actively in use", so an idle-but-running sandbox still bills. And snapshot storage "is metered from the time the sandbox is stopped until the sandbox is deleted", so stopping a session does not stop the bill.

The safety net has also closed. GitHub's page says: "During public preview, eligible GitHub accounts receive a $10 monthly entitlement to try cloud sandboxes. This entitlement is available through the end of July 2026." By that wording the entitlement expired three weeks before this launch, while the page still describes the preview in the present tense. A team that switches Copilot-in-Slack on today is paying from the first second.

One more trap sits in the same page: cloud sandboxes "are not part of the 'Bundled AI credits' budget type". If your finance team set a bundled AI credits budget and assumed it caps agent spend, it does not cap this. GitHub's instruction is to use a product-level or SKU-level budget instead, and to enable "Stop usage when budget limit is reached" if you want a hard stop.

Conflict three: the extra approval is already on

Both changelog posts describe the merge guardrail as something an admin turns on. The Slack post: "Repository administrators can require an additional approval for any pull request attributed to the Copilot app identity before it can merge." The Teams post adds the arithmetic: "If you require two approvals in a repository, with this enabled you will need three for Copilot-created pull requests."

Both docs pages say the opposite about the default. Identical wording on each:

Pull requests created in a shared context by Copilot use the app's identity. If you use repository rulesets, because these pull requests aren't attributed to a person, one more approval is required before merging, as long as the repository already requires at least one approval. This is enabled by default.

Read the conditions before you panic or relax. It fires only where you already use repository rulesets and those rulesets already require at least one approval. But where both are true, your merge threshold on agent-authored pull requests moved without anyone in your org changing a setting. If your release train assumes two approvals and you gate deploys on merge time, you now need three, and nobody sent you a ticket.

This is where the app-identity design bites. The docs draw a clean line: in a direct message Copilot "uses the permissions of your linked GitHub personal account", but "when you use Copilot in a shared context, such as a group thread or channel, Copilot creates artifacts, such as pull requests, under its app identity rather than your personal account." Same prompt, different author, different merge rules, depending only on whether you typed it in a DM or a channel.

"No additional IT lift" is not what GitHub's docs describe

Salesforce's Slack Code page makes a strong operational claim: agents in code channels "inherit Slack's built-in security model, permissions, and admin controls from day one, without any additional IT lift", working "with no new infrastructure or identities to manage". Slack's own post repeats it: "Slack Code inherits Slack's existing permissions and admin controls, so IT doesn't need to configure or audit anything new."

That is accurate about Slack. It is not accurate about the GitHub side of the same feature. GitHub's Slack docs page lists three separate gates:

  1. An org or enterprise owner must enable Copilot cloud agent and cloud sandboxes, because "Cloud sandbox policies share the same configuration as Copilot cloud agent policies."
  2. "For enterprise-owned repositories, administrators must install and configure the Slack GitHub app and specify which repositories the Slack app can access."
  3. Each individual links their GitHub account on first use, and sets a default repository per channel.

And the app identity is, by definition, a new identity to manage. It authors pull requests, it triggers the ruleset behaviour above, and it is not any human on your team.

The Teams path adds a fourth gate that most coverage will miss. GitHub's Teams docs page requires a second, unrelated preview to be switched on: "You must have Microsoft Public Developer Preview enabled for your Microsoft Teams client." Microsoft's own documentation describes that as a per-client toggle under Settings, About Teams, Early access, dependent on custom app upload being enabled for the tenant. Two stacked previews, two owners, before a single agent runs.

Who is affected, and how to tell if that is you

You are exposed to at least one of these three if any of the following is true.

Your repositories use rulesets with a required-approval count. The extra approval on Copilot-app pull requests is on by default and your merge threshold has already changed.

You run Copilot on Pro or Pro+ rather than Business or Enterprise. The Slack changelog says you are not eligible; the docs say you are. Do not build a rollout plan on the more generous of two contradictory pages.

Your AI budget guardrail is a bundled AI credits budget. It does not cover cloud sandboxes. Compute, memory and snapshot storage bill outside it.

Your team uses Microsoft Teams and your tenant has custom app upload disabled. The Teams integration will not start, and the blocker is on the Microsoft side, not GitHub's.

Guest accounts and outside collaborators are also out. Both docs pages carry the same line: "Guest members of a workspace, and outside collaborators to repositories are not able to start or steer a session." If contractors do a meaningful share of your delivery, chat-initiated agent work will route around them.

What to do this week

Read the whole thread before you mention the agent. GitHub's warning is unambiguous: Copilot "will capture the entire thread as context for your request", and "This context is stored in the artifacts the agent generates". An incident channel where someone pasted a customer record becomes training context for a pull request description. GitHub's mitigation is blunt and worth adopting as policy: use a direct message when you want to limit context.

Set a product-level or SKU-level budget on cloud sandboxes before you announce the feature internally, not after the first invoice. Enable the stop-at-limit option while you learn the shape of your usage.

Audit your rulesets and count your required approvals. If a repository requires two, expect three on agent-authored pull requests and tell your release managers before they discover it during a hotfix.

Decide, deliberately, whether agent work happens in DMs or channels. The choice is not cosmetic. It changes the author identity, the merge rules and how much of your Slack history ends up inside a pull request.

Pin the version of the truth you are working from. All four GitHub pages are marked "This feature is in public preview and subject to change", and none of the docs pages carries a publication or last-updated date. When the pages disagree, the changelog entries at least have a timestamp.

The honest read on all of this: the collaboration story is real and the plumbing is not finished. Chat-initiated agents are a good fit for the work that never gets a ticket, and a poor fit for anything where you cannot yet answer who authored the change and which meter paid for it.

India-specific considerations

For teams delivering from India, the thread-capture behaviour is the part to govern first. Under the Digital Personal Data Protection Act 2023, personal data pasted into a Slack or Teams thread and then absorbed into a pull request description has moved into a new system with a different retention path, and your consent and purpose-limitation records need to reflect that. The practical control is the one GitHub already documents: restrict agent invocation to channels where customer data is not discussed, and use direct messages for anything ambiguous. The second India-specific point is commercial. Cloud sandbox charges are billed in USD against the account that owns the sandbox, and GitHub's billing page notes that "If you are in a repository, the owner of the repository is billed" - which for outsourced delivery means the client's org, not the vendor's, unless you set that boundary explicitly in the contract.

Teams building this control layer usually pair it with a broader AI coding agent rollout governance programme, because the merge-approval change, the budget type and the identity question all land on the same platform team in the same week. Related reading: Copilot cloud agent automations and reasoning level configuration, Copilot MCP allowlists in enterprise managed settings, and AI agent identity governance for the non-human identity side of the app-identity problem.

What is still unknown

GitHub has not published a per-session AI credit consumption figure for cloud agent sessions started from chat, so the credit side of the bill cannot be modelled from primary sources yet. Neither docs page states what Slack or Microsoft retains from an agent session. Neither states whether Slack Connect or externally shared channels are supported. And no page gives a date for general availability or for the end of the public preview.

FAQ

Which Copilot plans can use the Slack integration?

GitHub's four pages disagree. The 21 August 2026 Slack changelog restricts the public preview to organizations on Copilot Business and Copilot Enterprise. The Slack docs page, the Teams docs page and the Teams changelog all say any paid Copilot plan qualifies. Confirm with GitHub before committing a rollout plan to either reading.

What does a Copilot cloud agent session cost?

Two meters run. Cloud agent sessions consume AI credits, per the Teams changelog. Cloud sandboxes bill separately at $0.000024 per compute second, $0.000003 per GiB second and $0.005 per GiB month. The $10 monthly preview entitlement was available through the end of July 2026, so new usage now bills from the first second.

Does the extra pull request approval apply automatically?

Both GitHub docs pages say it is enabled by default, while both changelog posts describe it as something administrators can require. The default applies only where you already use repository rulesets and those rulesets already require at least one approval. In that case a repository requiring two approvals will need three on Copilot-authored pull requests.

Why do Copilot pull requests need an extra approval at all?

Because of authorship. In a shared channel or group thread Copilot creates pull requests under its app identity rather than the requester's personal account. Rulesets treat an unattributed pull request as lacking a human author, so one more approval is required before merging. In a direct message Copilot uses your own account permissions instead.

Does Slack Code need new IT configuration?

On the Slack side, no. Slack and Salesforce both say code channels inherit existing Slack permissions and admin controls. On the GitHub side, yes. An owner must enable cloud agent and cloud sandboxes, enterprise administrators must install the Slack GitHub app and scope its repository access, and each user links an account.

What extra step does the Microsoft Teams version need?

GitHub's Teams documentation requires Microsoft Public Developer Preview to be enabled for the Teams client, on top of GitHub's own public preview. Microsoft documents that as a per-client toggle under Settings, About, Early access, and it depends on custom app upload being enabled for the tenant. Two separate previews must be active.

Can contractors and guests use chat-initiated agents?

No. Both GitHub docs pages state that guest members of a workspace and outside collaborators to repositories cannot start or steer a session with Copilot. Any conversation participant can add context, but only users with write access to the repository can trigger Copilot to make changes to code.

What context does the agent capture from a thread?

The whole thread. GitHub's documentation states that Copilot cloud agent captures the entire thread as context and that this context is stored in the artifacts the agent generates. GitHub's suggested mitigation is to send a direct message instead when you want to limit what the agent reads and retains.

How eCorpIT can help

eCorpIT builds the governance layer that chat-initiated coding agents need before a rollout: ruleset and approval-threshold audits, cloud sandbox budget design at the product and SKU level, and channel policies that keep customer data out of agent context. We are CMMI Level 5, MSME certified and ISO 27001:2022 certified, and our senior engineering teams run these reviews against your existing GitHub and Slack or Teams configuration rather than a template. Talk to us through /contact-us/ to scope a review before the first invoice lands.

References

  1. The new GitHub Copilot experience in Slack, GitHub Changelog, 21 August 2026
  2. Shared agentic work with GitHub Copilot in Microsoft Teams, GitHub Changelog, 21 August 2026
  3. Integrating Copilot cloud agent with Slack, GitHub Docs
  4. Integrating Copilot cloud agent with Teams, GitHub Docs
  5. Billing for cloud and local sandboxes for GitHub Copilot, GitHub Docs
  6. Budgets for usage-based billing, GitHub Docs
  7. Copilot changelog index, GitHub
  8. Slack Code: Where Your Team and Agents Build Together, Slack, 20 August 2026
  9. Introducing Slack Code: Agentic Coding for Teams, Salesforce, 20 August 2026
  10. Changelog, Vercel, 20 August 2026
  11. Public Developer Preview, Microsoft Teams, Microsoft Learn

Last updated: 21 August 2026.

Top comments (0)