GitHub Copilot Slack and Teams Update: How Should Teams Accept Agents? 2026 Checklist

A Slack or Teams request has produced an Agent task, but you can’t tell which repository or discussion it used.

Fastest fix: pilot only low-risk work, and verify preview access, task context, GitHub identity, repository binding, and interruption recovery before you allow a code change into review. A chat thread is not approval to merge. If the deliverable needs Xcode, test it on a real macOS build environment separately.

Who should use this runbook: Development teams turning Slack or Microsoft Teams conversations into GitHub issues, pull requests, or coding tasks.
Enterprise administrators enabling Copilot cloud agent, app policies, and cloud execution.
Platform engineers responsible for repository changes, long-running work, and recovery evidence.

Last updated September 27, 2026. Status and setup details were checked against GitHub’s September 25 update, the Slack integration guide, and the Teams integration guide. Recheck those sources before rollout; preview availability and eligibility can change.

Before connection: verify access, not assumptions

The September 25, 2026 update describes new context capabilities, task links, and some recovery improvements for GitHub Copilot in Slack and Microsoft Teams. GitHub labels the integrations public preview and says some capabilities are rolling out in stages. That makes the first acceptance question operational: can your organization use the feature now, with its current plan and policies? Check the announcement for the stated preview and rollout status.

There is an important qualification boundary. The announcement and the individual setup guides do not describe plan eligibility in exactly the same terms. Don’t resolve that difference by guessing or by applying the broadest interpretation. Check the current official wording, then verify whether the integration and task actions are actually visible to an authorized pilot account in your tenant. Record both the documentation consulted and the observed tenant state.

Before connecting either app, confirm:

• Organization eligibility: Which account and organization are signed in, and can the intended user access the preview?
• Administrator policy: Is the integration allowed by the organization’s Copilot access settings? Review GitHub’s organization access policy documentation.
• App authorization: Has the relevant Slack or Teams app been approved and installed with an appropriate scope?
• Cloud execution prerequisites: Is Copilot cloud agent available for the target organization and repository, with the required access and guardrails? Review GitHub’s cloud agent guardrails guidance.
• Preview timing: Are the required capabilities present for your tenant, or is the rollout still pending?

Keep a record of the settings and the pilot account’s observed access. A setup page shows how a connection should be made; it does not prove that a specific tenant has the same eligibility, policy, or rollout status.

Hold point: If the announcement, setup guide, and tenant view disagree, don’t widen access to “see if it works.” Keep the pilot blocked until an administrator can identify the applicable policy and confirm the tenant behavior.

At first connection: pin the account and repository

A working app connection is not yet a trustworthy task path. You need to know which GitHub identity performs the work, which repository receives it, and what that identity is allowed to do. Slack or Teams membership alone does not establish GitHub write permission.

Start with a dedicated pilot account or a named participant whose permissions you can inspect. Verify the signed-in GitHub account, the repositories the app can access, and the target repository’s write permissions. Check the default repository and branch where the integration presents them, but don’t treat a channel default as proof that every request explicitly names that repository.

Repeat the check in a direct conversation and in the shared channel you intend to use. These are separate contexts for testing: participants, app access, and the selected GitHub identity may not be the same. Confirm who can initiate a task, who can see its result, and which account’s permissions govern the change. Save administrator settings and the pilot account’s observations together so you can compare them after a policy update.

For a broader review of access boundaries, use this cloud execution and Agent acceptance guide alongside the integration-specific policies. Keep the question narrow: who can request a task, what repository can it reach, and what action can it take? Don’t infer answers from a successful sign-in.

First task: trace the discussion into the artifact

Use a representative, non-sensitive request. Make it specific enough to identify the intended repository and result, but do not put confidential attachments, credentials, or customer data into a preview workflow just to test context handling.

The update describes added context capabilities for Slack and Teams. For Slack, consult the current integration instructions for the documented handling of messages, links, and attachments. For Teams, consult the Teams guide for its documented treatment of images and forwarded content. Don’t assume that every part of a thread is always included, or that an attachment is interpreted exactly as a user sees it in the chat.

For the test, preserve an evidence chain:

• Identify the source conversation and the specific request that should drive the task.
• Record which repository and branch the task should use.
• Inspect the task details and any linked issue or pull request.
• Compare the artifact’s repository, branch, and content with the requested work.
• Confirm that the artifact links back to the expected source discussion, if the interface provides that link.
• Note which messages, attachments, images, or forwarded items are visible to the task and which are not.

The key boundary is data scope. A thread may contain decisions, corrections, and attachments beyond the initial request. Treat the entire accessible discussion as potentially relevant task context until your test and the official documentation establish what is passed through. Don’t use an unredacted production conversation as a shortcut to find out.

A task that creates an issue or pull request has demonstrated that a task and artifact were created. It has not demonstrated that the right context was used, the code is correct, the tests are adequate, or the change is safe to merge. Keep those acceptance decisions separate.

During collaboration: retest model and repository changes

A task can move away from its original assumptions during a conversation. Test model selection, repository changes, and artifact ownership as separate behaviors instead of treating an interactive session as a single, fixed configuration.

If the interface allows a model change, check whether the selection applies to the current conversation, the next task, or a wider scope. Record what the interface confirms; don’t infer persistence from one response. If your team depends on a particular model choice, make the choice visible in the acceptance record and retest after starting a fresh conversation.

For Slack, verify any updated defaults, such as the expected repository or task owner, against the behavior documented for your installation. Then submit a test task that explicitly names its repository. Compare the result with the channel default and confirm that the pull request belongs to the intended repository and links to the right source conversation. A default is a convenience, not a substitute for confirming the destination.

Treat the task link, issue or pull request, and source discussion as distinct records. If one is missing or points elsewhere, stop and investigate before anyone reviews the code. Keep human review, deterministic tests, and merge controls in place. GitHub’s cloud agent behavior and limitations documentation is useful for setting expectations, but your own acceptance still depends on the repository’s checks and review process.

After an interruption: inspect state before retrying

An interrupted conversation can leave you uncertain about whether the cloud task is idle, still active, or already finished. The update mentions some recovery improvements, but don’t convert that general statement into a guarantee that every task resumes safely or that a repeated request will be deduplicated. Verify the observable behavior in your own tenant and keep the result tied to the relevant task.

Use a controlled, low-risk task to check the following:

• Stalled work: Inspect the visible task status and any available plan or progress details. Record exactly what the interface reports.
• Expired reply: Check whether the conversation indicates that a response is no longer current, and whether the task itself still has an artifact or status to inspect.
• Idle reconnection: Reopen the conversation and confirm which task, repository, and source discussion are displayed before sending another instruction.
• Repository switch: Change the intended repository only in a test case. Check that the prior conversation or task does not continue under an old repository assumption.
• Retry behavior: Before repeating the request, search the linked issue or pull request and the task history available to you. Record whether a second artifact or answer appeared.

The purpose is not to prove that every failure mode has a product-level recovery path. It is to know what evidence your team can see and what procedure it should follow when that evidence is incomplete. If you cannot tell whether a task is still running, don’t issue a second write-capable request against the same work until an owner checks the task and repository state.

Rollout decision: compare evidence, then choose scope

Use this branch to choose the next action. It is a decision tool, not a product score: mark each condition from observed behavior and retained records.

• If preview access, admin policy, GitHub identity, and repository permissions all match the approved pilot scope: proceed with low-risk tasks in that scope. Otherwise, hold connection or task execution until the mismatch is resolved.
• If a test task’s discussion context, repository, artifact, and source link can be reconciled: continue the pilot with human review and existing merge controls. If a link or destination cannot be confirmed, restrict the pilot to non-writing tasks or pause it.
• If your team can inspect interrupted task state and check for duplicate artifacts before retrying: document that recovery procedure and test it with the pilot owners. If state is unclear, require an owner to inspect the task before another write-capable request.
• If deterministic checks and code review remain mandatory: keep them as merge gates. If a team expects chat completion to substitute for those controls, do not expand the rollout.
• If the deliverable requires Apple tooling: run a separate build acceptance test on real macOS with the required Xcode toolchain. If it does not, don’t make a Mac environment a prerequisite for Slack or Teams integration acceptance.

The final rollout record should make it possible for someone outside the pilot to answer: which account initiated the task, which discussion supplied context, which repository received the artifact, what happened after interruption, and which human or automated checks still gate a merge. A missing answer is a reason to narrow scope, not a reason to assume the default was correct.

Acceptance matrix

Task record template

No sample connection record or recovery result is presented here as a MacPull test. Keep your team’s actual evidence, redact sensitive content, and record observations rather than filling gaps with assumed product behavior.

FAQ

Connecting Slack or Teams

Use the current setup guide for the app you plan to use, then verify tenant access, administrator policy, GitHub identity, repository permissions, and cloud execution prerequisites in the actual environment. Because the announcement and setup documentation may phrase plan eligibility differently, an apparently successful installation is not enough. Record the tenant’s observed access before treating the connection as accepted.

Discussion context

The update describes new context capabilities, but you should not assume that every message or attachment is always passed into a task. Test the documented handling of Slack links and attachments or Teams images and forwarded content with a non-sensitive thread. Compare what the task can access with the resulting artifact, and record the limits you observe before using shared conversations that contain sensitive information.

Verifying a Teams pull request

Set the expected repository and branch explicitly in a low-risk test. Then compare the active GitHub identity, task information, pull request destination, and any link to the originating Teams conversation. Do not use the channel’s default repository as the only evidence. If the repository or source link does not match, stop before expanding write access and repeat the test with a smaller scope.

Recovery after an interruption

Check the visible task status and look for an existing issue or pull request before sending the same instruction again. Compare the repository and source discussion attached to any artifact, then record whether another response or artifact exists. If you cannot determine whether the original task is still active, have an owner inspect it before retrying; a conversation that appears idle is not proof that the cloud task stopped.

If your current workflow already depends on a general chat-to-code handoff, its weak points are often unclear source context, uncertain repository defaults, and retries that are hard to distinguish from the original task. Keep the Copilot pilot’s GitHub review and test gates in place; don’t replace them with a different execution environment. For teams that also need Xcode delivery, review the remote Mac and Xcode build boundary. A real macOS build is a separate requirement, not a prerequisite for Slack or Teams integration. When your team needs a temporary macOS test or build environment, compare MacPull plans against maintaining your own Mac; if your work is continuously heavy or needs local physical interfaces, ownership may be the better fit.

FAQ