GitHub Copilot appがBuild 2026でプレビュー拡大：使える対象、キャンバス、サンドボックス確認ポイント

3行まとめ

試せる対象有料Copilot中心

既存のCopilot Pro、Pro+、Business、Enterprise利用者がtechnical previewの対象になる。

企業の条件管理者設定が先

Business/Enterpriseではpreview featuresとCopilot CLI policyを確認してからpilotに進む。

評価する点作業の追跡性

session、canvas、diff、terminal、browser、PRをまたいで判断材料が残るかを見る。

確認日は2026年6月3日JST。technical previewでは機能名、対象、管理条件が変わる可能性がある。

• GitHubはMicrosoft Build 2026に合わせて、GitHub Copilot appのtechnical previewを既存のCopilot Pro、Pro+、Business、Enterprise利用者に広げた。Copilot Free利用者とCopilot未契約者は、現時点ではwaitlistから広いアクセスを待つ扱いだ。
• Business/Enterpriseで試す場合は、開発者がアプリを入れるだけでは足りない。組織またはenterprise側でpreview featuresとCopilot CLIが有効になっているか、sandbox、MCP、Agent Mergeをどの範囲で許可するかを先に確認したい。
• 今回のポイントは「デスクトップ版Copilotが出た」だけではない。issue、pull request、prompt、worktree、canvas、terminal、browser、cloud/local sandboxをまたいで、エージェント作業を見える状態で試せるかが導入判断の中心になる。

Microsoft Build 2026では、GitHub Copilot、Microsoft Foundry、Copilot Studio、Windows上のagent runtimeなど、開発者向けAIエージェントの発表がまとまって出ている。その中でもGitHub Copilot appは、日々の開発作業に直接触れる変更だ。GitHubの2026年6月2日付けChangelogとBlogでは、technical previewの対象拡大、canvases、cloud sessions、cloud automations、Copilot CLI sessionsとの連携、agentic browsing、rubber duckなどが説明された。

この記事では、2026年6月3日JST時点で確認できるGitHub公式発表、GitHub Docs、Microsoft Official Blogをもとに、GitHub Copilot appを試す前に見るべき条件を整理する。SNSやコミュニティでの課金・利用条件への関心は需要シグナルとして参考にするが、プラン、提供条件、管理者設定、sandboxの範囲は公式情報で確認する。

Microsoft Watch JapanはMicrosoft Corporationおよび関係会社とは非提携であり、本記事は投資助言、売買推奨、目標株価の提示を目的としない。MSFTの企業動向を見る補助線として扱う場合も、ここでの主役は株価ではなく、GitHub Copilotを使う開発者と導入企業が何を確認すべきかだ。

Build 2026全体の流れを追う場合は、公開済みのMicrosoft Build 2026公式確認ポイントと、月内更新を集める2026年6月 重要トピックまとめもあわせて確認したい。

GitHub Copilot app preview拡大で何が変わったか

対象拡大

GitHub Copilot appのtechnical previewが、既存のCopilot Pro、Pro+、Business、Enterprise利用者に広がった。

作業面の変化

issue、pull request、prompt、過去sessionから作業を始め、worktree、branch、diff、PRまで追いやすくする。

waitlist扱い

Copilot Free利用者とCopilot未契約者は、現時点では広いアクセスを待つためにwaitlistへ進む。

一般提供ではなくtechnical previewとして読むと、試せることと本番標準化を分けて判断しやすい。

今回の発表を一言でいうと、GitHub Copilot appのtechnical previewが、より広い既存Copilot利用者に開いたということだ。GitHub Changelogは2026年6月2日、GitHub Copilot app technical previewが既存のCopilot Pro、Pro+、Business、Enterprise顧客に利用可能になったと説明している。Windows、macOS、Linux向けのアプリとして案内されている点も、GitHubの製品ページとDocsで確認できる。

ただし、ここで大事なのは「一般提供」ではなくtechnical previewであることだ。GitHub Docsも、GitHub Copilot appはtechnical previewであり変更される可能性があると明記している。したがって、個人利用では試せる範囲が広がったと見てよい一方、企業導入では本番の標準ツールにする前にpilotの範囲を切る必要がある。

公式確認できる変更

根拠

GitHub Copilot appは、GitHub上の作業を起点にエージェントセッションを始めるためのデスクトップ体験として説明されている。issue、pull request、prompt、過去のsessionから作業を始め、connected repositoriesをまたいでMy Workから状態を見る。複数のagent sessionsは、それぞれ独立したgit worktreeとbranch、conversation、task stateを持つ。これは、単にチャット欄が別アプリになったというより、エージェントに任せる作業の状態を切り分けて追うための作業面だ。

GitHub Blogは、agentic developmentが広がるにつれて、複数のagent作業、review、CI、merge前の確認が散らばりやすくなったと説明している。Copilot appはその問題に対して、session、canvas、diff、terminal、browser、pull requestを同じ作業の流れに置こうとしている。

対象外ではなくwaitlist扱いのユーザー

条件

Copilot Free利用者とCopilot未契約者は、現時点では広いアクセスを待つためにwaitlistへ参加する扱いだ。ここは誤読しやすい。Freeユーザーが永久に対象外という意味ではなく、2026年6月3日時点の公式説明では、既存の有料Copilot利用者とBusiness/Enterprise利用者が先に試せる、という整理になる。

また、Changelogには既存Pro+利用者がCopilot Maxへアップグレードできる案内もある。これはより多い利用量を求めるユーザー向けの話であり、Copilot app previewを試せるかどうかとは分けて読むべきだ。preview対象、利用量、課金、model選択は、それぞれ別の確認軸になる。

Build 2026の文脈

評価基準

Microsoft Official BlogはBuild 2026の全体像として、開発者がAIエージェントを作り、運用し、管理するための基盤を強調している。GitHub Copilot appもその流れの一部だが、細かな提供条件や機能範囲はGitHub Changelog、GitHub Blog、GitHub Docsへ戻って確認するのがよい。

特に、Microsoft側ではWindowsをagent-native runtimeへ寄せる文脈やMicrosoft Execution Containersのpreviewも語られている。一方、GitHub Copilot appの導入判断では、GitHubのaccount、organization/enterprise policy、Copilot CLI、sandbox、MCP、PR運用が直接の確認対象になる。Build全体の大きなストーリーに引っ張られすぎず、実際に触る設定へ落とすことが大切だ。

試せる対象プランと管理者設定

利用者区分	previewの扱い	先に見る条件	注意点
Copilot Pro / Pro+	既存利用者は試用対象	契約状態、GitHubアカウント、対応OS、接続するrepository	重要repositoryへ広げる前に、影響の小さい作業で差分とログを確認する。
Copilot Business	組織設定が必要	organizationのpreview features、Copilot CLI policy、対象ユーザー	開発者がアプリを入れるだけではなく、管理者側の許可範囲を先に決める。
Copilot Enterprise	enterprise設定が必要	enterprise policy、対象organization、対象repository、audit logging	sandbox、MCP、Agent Mergeの範囲をpilot前に整理する。
Copilot Free / 未契約	現時点ではwaitlist	広いアクセスの案内、今後の公式更新	永久に対象外ではなく、2026年6月3日JST時点では待機扱いとして読む。

プランの優劣ではなく、試せる条件、管理者の関与、待機扱いを分けて確認する表。

最初に見るべき分岐は、個人利用者か、Business/Enterprise配下のユーザーかだ。個人のCopilot ProまたはPro+利用者は、GitHub Docs上の説明ではGitHub Copilot app repositoryからアプリを入手して試せる対象に入っている。Business/Enterpriseユーザーも対象だが、組織またはenterpriseでpreview featuresとCopilot CLIが有効になっている必要がある。

この条件は、導入企業にとってかなり重要だ。GitHub Copilot appはCopilot CLIを土台にしており、session historyやCLI sessionとの接続も説明されている。CLIの利用を止めている組織で、デスクトップアプリだけを個別に開くという読み方は危うい。

個人プランで見ること

確認項目

Copilot ProまたはPro+で試す場合、最初に確認するのは契約状態、利用するGitHubアカウント、対応OS、preview注意書きだ。GitHubの製品ページでは、GitHub Copilot appはmacOS、Windows、Linux向けに案内されている。自分のGitHubアカウントでアクセスできるか、どのrepositoryを接続するか、sessionをlocal folderから始めるのかGitHub repositoryから始めるのかを分けて確認したい。

個人利用での上振れは、複数の作業をparallel sessionsとして分けられることだ。たとえば、issue調査、pull requestの修正、release noteの下書きといった作業を別々のworktreeとbranchで動かせる。下振れは、previewであるため、UI、機能名、利用量の扱い、対応modelが変わり得ることだ。仕事用の重要repositoryにいきなり広げるより、影響の小さいrepositoryで差分とログの追いやすさを見ておきたい。

Business/Enterpriseで見ること

条件

Business/Enterpriseでは、利用者本人より先に管理者の確認が必要になる。GitHub Docsは、Copilot BusinessまたはCopilot EnterpriseでGitHub Copilot appを使うには、organizationまたはenterpriseでpreview featuresとCopilot CLIが有効になっている必要があると説明している。

ここで見るべき項目は、対象ユーザー、対象organization、対象repository、Copilot CLI policy、MCP serverの接続可否、sandbox policy、Agent Mergeの扱い、audit log、課金監視だ。特にMCPやskillsは、エージェントが外部ツールや独自手順を使うための入口になる。どのserverを許可するか、secretや内部データに触れる可能性があるか、失敗時に誰が止めるかをpilot前に決めておきたい。

請求面をどこまで見ておくか

注意点

GitHub Copilot appのpreview拡大と、Copilot全体の課金変更は別の話だ。しかし、読者の関心としてはつながっている。Copilot app、cloud sessions、Agent Merge、Copilot code reviewを同じ開発ワークフローで使い始めると、AI CreditsやGitHub Actions minutesの見方も必要になる。

この点は、すでに公開済みのGitHub Copilot code reviewの課金変更で整理している。今回の記事では、Copilot app自体のpreview条件を主語にし、費用の詳細はGitHub公式Docsと自社アカウントの利用状況で再確認する、という位置づけにとどめる。

キャンバスと並列agent sessionsで作業面はどう変わるか

1. 1Issue / Prompt / PR

   issue、pull request、prompt、過去sessionから作業を始める。

2. 2作業を切り分ける

   各sessionが独自のworktree、branch、conversation、task stateを持つ。

3. 3意図を作業対象に落とす

   plan、browser session、terminal、checklistなどを見ながら編集、承認、方向修正を行う。

4. 4差分を確認する

   どのsessionがどの変更を作ったかを追い、review対象を明確にする。

5. 5動作を検証する

   test、build、画面確認などを、判断材料として作業の流れに残す。

6. 6reviewへ進める

   pull requestで説明、checks、review commentへの対応を確認する。

速さだけでなく、あとから人間がplan、diff、検証結果を追えるかがpilotの評価軸になる。

GitHub Copilot appの見どころは、agent sessionを「頼んだら終わり」の箱にしないところにある。GitHub Changelogは、sessionをissue、pull request、prompt、過去sessionから始められること、各sessionが独自のgit worktreeとbranchを持つこと、planとdiffを確認し、integrated terminalとbrowserで動作を検証し、pull requestへ進めることを説明している。

これまでのAI coding assistantは、IDEやchatの中で回答やpatchを出すことが中心だった。Copilot appはそこから一歩進んで、作業の状態、差分、検証、PRの流れを同じ場所で追うことを狙っている。だから、導入時に見るべきなのは「どれだけ速くコードを書いたか」より、「人間があとから何を見て判断できるか」だ。

My Workと複数session

評価基準

My Workは、connected repositoriesをまたぐissue、pull request、active sessions、automationsを見る入口として説明されている。複数のagent sessionsを同時に動かす場合、作業ごとにbranch、files、conversation、task stateが分かれているかが重要になる。作業が速く見えても、どのsessionがどのdiffを作ったか分からないなら、review負荷はむしろ増える。

最初のpilotでは、ひとつの大きな機能開発を任せるより、小さなissue、軽いrefactor、review commentへの対応、release note作成のように、期待する成果物が見えやすいタスクから始めたい。GitHub Docsでは、session modeとしてInteractive、Plan、Autopilotが説明されている。初期段階では、PlanやInteractiveで人間の確認点を残すほうが評価しやすい。

Canvasesは何を解決するか

根拠

Canvasesは、今回の発表で特に重要な追加要素だ。GitHubはcanvasを、humanとagentが同じwork surfaceを使い、agentが更新し、開発者が編集、並べ替え、承認、方向修正できる仕組みとして説明している。plan、pull request、browser session、terminal、release checklist、incident、dashboard、workflow stateなどを扱う面になり得る。

これはchatの代替ではない。chatは意図や曖昧な部分を話す場所で、canvasはその意図が具体的な作業対象として見える場所だ。長いchat transcriptの中から「いま何ができているのか」を探すのではなく、作業物そのものを見て、人間が修正し、agentがそこから続ける。ここが導入評価の焦点になる。

terminal、browser、diffで検証する流れ

確認項目

GitHub Copilot appでは、planとdiffを見て、integrated terminalとbrowserで検証し、pull requestに進める流れが説明されている。さらに今回のChangelogでは、agentic browsingとして、agentがintegrated browserを操作し、click、type、screenshotなどを通じてUI変更を検証できるようになったとされている。

ただし、記事としては「agentが自動でUI検証を終える」と断定しない。実際に見るべきなのは、どの操作をしたか、どの証拠で完了と判断したか、人間が再現できるかだ。browserやterminalが統合されているからこそ、test command、preview、screenshot、PR diff、review commentを同じpilotログとして残せるかを確認したい。

cloud/local sandboxを試す前に見るポイント

項目	local sandbox	cloud sandbox	共通して見ること
実行場所	手元の開発環境に近い隔離環境	GitHub hostedの一時的なLinux sandbox	どのtaskをどちらで動かすかを先に決める。
filesystem	触れるdirectoryとsecretへの到達可能性を確認	repositoryと作業対象の範囲を確認	不要なファイルや資格情報を読ませない設計にする。
network	社内proxy、外部接続、policy違反時の挙動を確認	接続先、利用量、企業policyの継承範囲を確認	許可した通信とログに残る通信を分けて見る。
pilot条件	開発者の手元で止め方を確認	対象ユーザー、対象repo、費用監視を確認	sandbox policy、audit logging、停止条件を文書化する。

セキュリティに関わる比較では勝敗ではなく、どの条件なら試せるかを明確にする。

GitHub Copilotがagentic workflowへ進むほど、shell command、filesystem、network、tool executionへの不安は大きくなる。GitHub Changelogは2026年6月2日、cloud and local sandboxes for GitHub Copilotがpublic previewになったと発表した。これは、Copilotがlocalまたはcloudの隔離環境でtool executionを行うための仕組みとして説明されている。

ここで避けたいのは、「sandboxがあるなら安全」と短く結論づけることだ。sandboxは安全を考える入口であり、何を隔離し、何を許可し、どのpolicyを適用し、どこにログを残すかまで確認して初めて意味を持つ。

local sandboxで見ること

条件

local sandboxは、Copilot session内で/sandbox enableを使うことで、Copilotが開始するshell command executionを制限付きで動かす仕組みとして説明されている。Changelogでは、filesystem、network、system capabilitiesへのrestricted access、macOS、Linux、WindowsをまたぐMicrosoft MXC technology、IntuneやMDMによるpolicy構成にも触れている。local sandboxesはstandard GitHub Copilot seatに含まれるという説明もある。

pilotでは、どのdirectoryに触れるのか、network accessはどう制限するのか、secretやtokenを見ない設計になっているか、失敗時にsessionを止められるかを見る。local環境は手元の開発体験に近いぶん、うっかり広いfilesystem権限を渡す危険もある。

cloud sandboxで見ること

確認項目

cloud sandboxは、copilot --cloudでGitHub hostedのisolated, ephemeral Linux sandboxを起動する説明になっている。GitHub Changelogは、既存のCopilot cloud agent policiesを継承し、クラウド側の隔離環境でtaskを動かし、複数のCopilot taskを並列化したり、compute-intensiveな作業をlocal resourceから切り離したりできると説明している。

ただし、cloud sandboxの詳細な料金、policy、接続先、利用量、対応機能は変わりやすい。企業で試す場合は、cloud sandboxを使えるユーザー、対象repo、外部network、secret access、log、保存期間、費用監視を事前に決める必要がある。

sandbox public previewで避けたい誤解

注意点

public previewは、試しやすくなったという意味であって、全社標準の実行環境として完成したという意味ではない。preview中は対象機能、対応環境、管理者設定、ログ粒度が変わる可能性がある。安全確認の表では、少なくともfilesystem access、network access、secret access、repository権限、企業proxy、audit logging、policy違反時の停止方法を並べたい。

この章は、セキュリティ担当者にも読まれる前提で書くべきだ。開発者にとっての便利さと、管理者にとっての制御可能性は同じではない。local sandboxとcloud sandboxを比較するときは、実行場所だけでなく、誰がpolicyを作り、誰が例外を承認し、誰がログを見るかまで含める。

MCP、skills、Copilot CLI、Agent Mergeはどこで使い分けるか

MCP servers外部ツール接続

接続先、読み書き範囲、secret、社内データ、ログ、serverの信頼性を確認する。

skills / automations繰り返し手順の再利用

便利な作業テンプレートが、誤った操作の反復にならないようreview方法を決める。

Copilot CLIterminal中心のagent作業

rubber duck、prompt scheduling、voice inputと、app側のMy Workとのつながりを見る。

Agent MergePR完了支援

review comments、failing checks、merge条件への対応を、既存のreviewsとchecksの上で扱う。

管理者は機能名の多さより、接続、再利用、実行、mergeの責任境界を分けてpilot範囲を決める。

Build 2026周辺のGitHub Copilot更新は数が多い。Copilot app、Copilot CLI、sandbox、MCP、skills、Agent Merge、cloud automationsを全部まとめて「エージェント機能が増えた」と書くと、導入判断には使いにくい。ここでは役割を分けて読む。

MCP serversは外部ツールやデータへの接続、skillsは繰り返し使う手順や専門知識の再利用、Copilot CLIはterminal中心のagent作業、Agent Mergeはpull requestをreview、checks、merge条件へ進める支援と見るのがよい。

MCP serversとskills

管理者の確認項目

GitHub Changelogは、Copilot appのrecapとして、各sessionでmodelを選び、MCP serversで外部ツールを接続し、recurring workをreusable skillsやscheduled automationsとしてpackageできると説明している。これは強力だが、管理者にとっては接続先と権限範囲の確認が増えるということでもある。

MCP serverを許可する前に、接続先、読み取りと書き込みの範囲、secretの扱い、社内データに触れる可能性、エラー時のログ、serverの信頼性を確認したい。skillsも同じだ。便利な作業テンプレートは、繰り返し間違えるテンプレートにもなり得る。pilotでは、skillがどの操作を自動化し、誰が内容をreviewし、repositoryにどう保管されるかを見る。

Copilot CLI refresh

根拠

同じ2026年6月2日、GitHubはCopilot CLIのrefreshも発表している。rubber duck、prompt scheduling、voice inputは一般提供になり、新しいterminal interfaceは/experimentalで試せる位置づけだ。rubber duckは、plan、design、implementation、testsに対して別の視点から批評を返すbuilt-in agentとして説明されている。

このニュースをCopilot appと切り離しすぎないほうがよい。Business/EnterpriseでCopilot appを使う条件にCopilot CLI policyが関わるため、CLIを許可するかどうかはappの導入条件にもなる。開発者にとっては、CLI sessionsがappのMy Workに現れることで、terminalとdesktop appの作業履歴がつながるという意味もある。

Agent Merge

条件

Agent Mergeは、Copilotがpull requestをreview、checks、merge条件へ進める部分に関わる。GitHub BlogとChangelogでは、review commentsへの対応、failing checksの修正、条件が満たされた場合のmerge支援が説明されている。ここで大事なのは、既存のreviews、checks、merge requirementsを飛ばす道具のように扱わないことだ。

企業でpilotするなら、Agent Mergeにどこまで任せるかを段階化したい。CIをgreenに戻すところまでか、review feedbackへの対応までか、条件が満たされたらmergeするところまでか。review bypassに見える運用は避け、責任者、承認条件、ログ、取り消し手順を明確にする。

開発者と管理者のpilotチェックリスト

担当	試す前	試験中	止める条件
開発者	対象プラン、アプリ入手先、接続repo、session modeを確認	prompt、plan、diff、terminal、browser、PRの流れを追う	sessionの状態や差分の責任範囲が追えない
チームリード	小さなissue、軽いrefactor、review comment対応を選ぶ	既存checks、reviewコメント、説明の質を確認	canvasやdiffの見方がチームに定着しない
管理者	対象ユーザー、対象repo、preview features、Copilot CLI policyを決める	sandbox、MCP、skills、Agent Merge、billing monitorを確認	権限が広すぎる、費用監視が追いつかない
セキュリティ / 法務	secret access、network policy、audit logging、責任境界を確認	ログ、停止方法、外部接続、PR automationの扱いを見る	secret accessが不透明、review bypassの懸念が残る

本番導入へ進む条件は、派手なdemoではなく、日常業務で検証可能なdiffとログが再現できること。

GitHub Copilot appは、今すぐ全社導入するかどうかを決めるより、まず小さなpilotで「任せた作業を追跡できるか」を見るほうが向いている。technical previewの段階では、機能の広さより、止め方、見え方、責任境界を確認したい。

開発者が初日に見ること

確認項目

開発者は、対象プラン、preview注意書き、アプリの入手先、接続するrepository、session mode、model、reasoning effort、worktree、diff、terminal、browser、pull requestの流れを確認する。最初のタスクは、影響の小さいissueか、既存PRの小さな修正がよい。

評価基準は、作業が速く終わったかだけではない。どのpromptから始まり、どんなplanを出し、どのdiffを作り、何をterminalやbrowserで確認し、どのPRに残ったかを追えるかを見る。agentic browsingやrubber duckを使う場合も、その判断がログやcanvas上で理解できるかを確認する。

管理者がpilot前に決めること

停止条件

管理者は、対象ユーザー、対象repo、preview features、Copilot CLI policy、sandbox policy、MCP server、skills、scheduled automations、Agent Merge、cloud sandbox、billing monitor、audit loggingを先に整理する。特にBusiness/Enterpriseでは、利用者の熱量だけで進めると、後から「誰が何を許可したのか」が分からなくなる。

停止条件も先に決めたい。secret accessが不透明、権限が広すぎる、network policyが説明できない、費用監視が追いつかない、Agent Mergeの責任境界が曖昧、review bypassの懸念がある、ログが不足している。このどれかが出たら、pilotの範囲を戻す。

本番導入へ進める条件

上振れと下振れ

本番導入へ進める条件は、派手なdemoではなく、日常業務で再現できることだ。小さなissueやreview feedbackで、検証可能なdiff、再現可能なtest、既存checksとの整合、reviewコメントへの説明、費用と利用量の見える化が確認できれば、対象repoや対象チームを少しずつ広げられる。

逆に、sessionの状態が追えない、canvasやdiffの見方がチームに定着しない、sandboxとpolicyの説明が弱い、MCPやskillsの接続先が整理されていない、Agent Mergeが誰の責任で動くか曖昧な場合は、preview観察に戻したほうがよい。GitHub Copilot appは、開発者体験を軽くする可能性がある一方で、チームのreviewとgovernanceを見直すきっかけにもなる。

次に読むなら

Microsoftの公式発表、GitHub Copilot、Azure、Microsoft 365 Copilot、Windowsの更新を継続して追う場合は、製品・サービス・ソリューションカテゴリも参照できる。記事公開後の更新通知はニュースレター側で扱う方針だが、本文の判断材料を置き換えるものではない。

更新履歴

1. 2026年6月3日JSTGitHub Copilot app preview拡大を整理

   GitHub Changelog、GitHub Blog、GitHub Docs、Microsoft Official Blogを確認し、対象プラン、管理者設定、canvases、sandbox、Copilot CLI refreshを本文に反映した。

previewやexperimentalの要素は、公開後も公式DocsとChangelogで更新状況を確認する。

• 2026年6月3日JST: GitHub Changelog、GitHub Blog、GitHub Docs、Microsoft Official Blogを確認し、GitHub Copilot app technical preview拡大、Business/Enterpriseの条件、canvases、sandbox public preview、Copilot CLI refreshの範囲を整理した。

---

次に読むなら

参照した主な情報源

• GitHub Changelog, "Expanded technical preview availability for the GitHub Copilot app"

Expanded technical preview availability for the GitHub Copilot app

• GitHub Blog, "GitHub Copilot app: The agent-native desktop experience"

GitHub Copilot app: The agent-native desktop experience

• GitHub Docs, "Getting started with the GitHub Copilot app"

https://docs.github.com/en/copilot/how-tos/github-copilot-app/getting-started

• GitHub Docs, "Working with agent sessions in the GitHub Copilot app"

https://docs.github.com/en/copilot/how-tos/github-copilot-app/agent-sessions

• GitHub Changelog, "Cloud and local sandboxes for GitHub Copilot now in public preview"

Cloud and local sandboxes for GitHub Copilot now in public preview

• GitHub Changelog, "Copilot CLI: Improved UI, rubber duck, prompt scheduling, and voice input"

Copilot CLI: Improved UI, rubber duck, prompt scheduling, and voice input

• Microsoft Official Blog, "Microsoft Build 2026: Be yourself at work"

https://blogs.microsoft.com/blog/2026/06/02/microsoft-build-2026-be-yourself-at-work/