GitHub Copilot Multi-Repo Chat Needs an Authority Gate

The production verdict

Multi-repository chat is useful when a bug or change genuinely crosses services. It also compresses several different control planes into one natural-language interaction. The person who mentions @GitHub, the people whose messages become context, the identity that creates the artifact, the GitHub App installation, the selected repositories and the humans allowed to merge are not one principal.

Enable the feature for a bounded pilot only when your session admission record can answer five questions before work starts:

1. Which messages may become implementation context?
2. Who is allowed to trigger or steer this action-bearing session?
3. Will the artifact be attributed to a linked person or the GitHub App?
4. Which exact repositories and branches are in scope?
5. Which repository rules and accountable reviewers still control merge?

The release rule is simple: a chat mention can request work. It cannot grant itself repository authority or approve the result.

GitHub's October 15 changelog says @GitHub can now create issues, make code changes, track pull requests and investigate bugs across repositories without starting a new conversation. This article accepts that product capability and supplies the missing operating contract a platform team needs before broad enablement.

What changed, and what did not

The new capability removes a conversation boundary. A frontend and backend investigation can stay in one Slack or Teams thread, and the agent can use several repositories in the same task. That is a workflow improvement. It does not make the channel, its participants or the agent a repository owner.

GitHub's current Slack integration documentation and Teams integration documentation describe the controls that remain:

• both integrations are public preview and subject to change;
• a paid Copilot plan, the integration and enabled cloud-agent or sandbox policy are prerequisites;
• the entire thread becomes decision context and that context is stored in generated artifacts;
• a direct message uses the linked GitHub personal account for actions;
• a shared thread or channel creates artifacts under the GitHub App identity;
• only a user with write access to the repository can trigger code changes;
• other conversation participants may add context, while guests and outside repository collaborators cannot start or steer the session;
• enterprise administrators choose which repositories the app can access.

The Slack app also has a broad functional permission surface. GitHub's Slack permissions reference lists code read access, read access to checks and repository objects, write access to actions, issues, deployments, pull requests and content, plus workflow read and write access. That list is not evidence that every session should exercise every capability. It is the maximum installed surface from which each task needs a smaller effective authority.

Separate context, trigger, execution and merge authority

The most important design choice is to retain four facts instead of one generic user asked Copilot event.

A shared channel is especially easy to misread. GitHub documents that only a user with write access can trigger code changes, yet the entire thread can contribute context. A product manager's clarification may be valuable input without giving that person code authority. A security engineer may identify a forbidden path without becoming the implementer. An outside participant should not be able to steer the session at all.

This is the same admission principle used in the tested comment-triggered coding-agent controller: matching text identifies a request, not authority. The collaboration surface changes, but the separation does not.

Use an explicit session admission manifest

Do not reconstruct the decision from a finished pull request. Persist the manifest before the cloud agent starts.

{
  "session_id": "slack-C07-thread-1842",
  "platform": "slack",
  "surface": "shared",
  "action": "pull_request",
  "thread": {
    "message_range": "171-188",
    "context_class": "internal",
    "context_approved": true
  },
  "initiator": {
    "github_login": "octo-platform-owner",
    "workspace_membership": "member",
    "write_repositories": ["acme/web", "acme/api"]
  },
  "steering_participants": [
    { "id": "slack-U42", "workspace_membership": "member" }
  ],
  "requested_repositories": ["acme/web", "acme/api"],
  "app_installation_repositories": ["acme/web", "acme/api", "acme/docs"],
  "ruleset": {
    "base_approvals": 1,
    "additional_copilot_approval": true
  }
}

The requested repository list should be explicit whenever the task spans more than one repository. GitHub documents a shared channel default repository and says the first session can establish that default when none exists. The default is convenient for a single-repository channel. It is too weak to serve as the retained scope of a multi-repository change because the channel setting is shared and can change.

The context classification also needs a customer-owned policy. GitHub warns that the entire thread is captured and stored in the artifacts the agent generates. If a thread includes incident secrets, customer data, privileged legal discussion or unrelated personnel context, a working agent is still the wrong outcome. Start a narrower thread or direct message whose retained context is acceptable.

Run a deterministic gate before the session

The following dependency-free evaluator is the core of the retained reference model. It resolves the actor, normalizes the repository set, checks app and human authority, enforces context policy and computes the effective approval count.

import { createHash } from "node:crypto";

const unique = (items = []) => [...new Set(items)].sort();
const missing = (wanted, available) => {
  const have = new Set(available);
  return wanted.filter((item) => !have.has(item));
};

export function admit(input) {
  const repos = unique(
    input.requestedRepos?.length
      ? input.requestedRepos
      : [input.defaultRepo].filter(Boolean),
  );
  const reasons = [];

  if (!input.appInstalled) reasons.push("app_not_installed");
  if (!input.cloudAgentEnabled) reasons.push("cloud_agent_disabled");
  if (!input.sandboxEnabled) reasons.push("sandbox_disabled");
  if (!repos.length) reasons.push("repository_not_selected");
  if (repos.length > 1 && !input.explicitRepoSet) {
    reasons.push("multi_repo_scope_not_explicit");
  }
  if (input.initiator.membership !== "member") {
    reasons.push("initiator_not_internal_member");
  }
  if (
    input.surface === "shared" &&
    input.steeringParticipants.some((p) => p.membership !== "member")
  ) {
    reasons.push("guest_or_outside_steering");
  }
  if (missing(repos, input.appRepos).length) {
    reasons.push("app_missing_repository_access");
  }
  if (missing(repos, input.initiator.writeRepos).length) {
    reasons.push("initiator_missing_write_access");
  }
  if (!input.threadContextApproved) {
    reasons.push("thread_context_not_approved");
  }
  if (!input.allowedContextClasses.includes(input.contextClass)) {
    reasons.push("context_class_not_allowed");
  }

  const actor =
    input.surface === "dm" ? "linked_personal_account" : "github_app";
  const base = Math.max(0, input.ruleset.baseApprovals);
  const effectiveApprovals =
    input.surface === "shared" &&
    base >= 1 &&
    input.ruleset.additionalCopilotApproval
      ? base + 1
      : base;
  const receipt = { actor, repos, effectiveApprovals, reasons };

  return {
    admitted: reasons.length === 0,
    terminal: reasons.length ? "BLOCKED" : "READY_FOR_REVIEW",
    receipt,
    digest: createHash("sha256")
      .update(JSON.stringify(receipt))
      .digest("hex"),
  };
}

The retained implementation expands that function with platform and action validation plus a stable receipt of initiator, steerers, repository grants and ruleset state. It passes twenty of twenty synthetic checks. The cases cover unsupported surfaces, disabled prerequisites, implicit multi-repository scope, missing app access, missing human write access, guest or outside steering, rejected context classes and the shared-channel approval calculation.

Those tests prove only that the policy behaves as written. They do not prove GitHub availability, protect against a compromised workspace, establish code correctness or show that a generated change is safe to merge.

A pull request is the handoff, not the outcome

Direct and shared conversations produce different attribution. In a direct message, GitHub says actions use the linked personal account. In a shared context, the app identity creates the pull request. Your review policy should preserve that distinction rather than forcing both paths into one audit label.

GitHub's ruleset reference adds an important safeguard for unattributed Copilot pull requests. When a ruleset already requires at least one approval, the additional-Copilot-approval setting increases that count by one. It is enabled by default. A one-approval rule therefore becomes two for a shared-context app pull request.

The edge case matters: GitHub says the setting has no effect when the ruleset requires zero approvals. A repository that records changes through pull requests without requiring human approval still requires zero. Enabling the collaboration integration does not invent a merge gate.

Keep the rest of the release evidence outside the chat transcript:

• the exact base and head repositories, branches and commit SHAs;
• the thread-context digest and admission receipt;
• the app installation and initiator access observed at admission time;
• required tests, code scanning and protected-path owners;
• stale-approval behavior after the agent pushes another commit;
• human disposition of the final diff;
• merge commit and deployment receipt, or an explicit stopped terminal.

Our Copilot security review versus CodeQL guide covers the downstream enforcement boundary. Chat context can explain why a change is wanted. It cannot replace repository checks or accountable review of what the change actually does.

Roll out one collaboration path at a time

Where the workflow breaks first

• The wrong context crosses into code. A thread contains customer or incident material that should not be retained in generated artifacts. Block the session and create a smaller approved context bundle.
• A channel default chooses the repository. A shared default is stale or changed for another team. Require the repositories in the admitted manifest.
• One user can write only half the change. Multi-repository investigation spans two codebases, but the initiator lacks write access to one. Do not let the app's broader installation fill the gap.
• An unauthorized participant steers. A guest or outside collaborator adds an action-bearing correction. Preserve useful human discussion, but exclude it from the executable session and route it to an internal owner.
• The app identity hides human responsibility. A shared-context pull request appears under the app. Keep the trigger, steerers and reviewers as separate evidence.
• Zero approvals stays zero. The additional Copilot approval cannot help a ruleset configured with no required approval. Fix the repository policy before enabling the shared write path.
• A later push invalidates the review. Require approval of the current diff and dismiss stale approvals where the risk warrants it.
• The sandbox is mistaken for business authority. Isolation limits execution. It does not decide whether the thread, repository set or requested behavior is permitted.

Frequently asked questions