“Copilot Workspace vs Copilot Chat” is now a historical comparison, not a choice between two equivalent current purchase options. The official Copilot Workspace manual describes a GitHub Next experiment and was archived in September 2025. Do not use its preview screens as instructions for today’s Copilot.
For current work, decide whether you want interactive help in your editor or a delegated task that produces a pull request. Modern Copilot in VS Code can work across files; it is not limited to a single selected function.
Official documentation checked October 14, 2026.
Separate the Historical Preview From Current Features
Workspace explored a task-first process: describe a change, inspect a plan, review generated code and validate the result. Those concepts remain useful. They do not establish that a current repository has an “Open in Workspace” button, that every Copilot subscription includes the former preview, or that another product is a one-to-one rename.
Similarly, “Chat” describes an interaction surface, not a promise of read-only or single-file behavior. The selected agent role, tools, permissions and execution environment determine what can happen. Inspect those controls before sending a request.
Use an Editor Session for Interactive Work
Open your project in VS Code and start a new Chat session. Confirm the session target, selected role, model and permissions. The current agent quickstart includes editing files and running validation tools. This is broader than the old description of Chat as code suggestions for the active file only.
For explanation, ask a narrow question and identify the relevant files. For a change across modules, give acceptance criteria and ask for a plan first. The planning guide documents /plan and the review controls. Read the full plan, check which files are in scope, and approve implementation only when ready.
Do not press Tab expecting it to universally apply an entire multi-file Chat result. Review the changes through the controls offered by that session. Run tests independently and inspect the resulting diff.
Closing a panel is not the same as deleting a session. Current VS Code has session history and ways to return to earlier work. Save important specifications in the repository as well: conversation history alone is not an ideal permanent requirements record.
Use a Cloud Task for a Pull-Request Workflow
When you want to delegate a well-scoped repository change, consult Copilot cloud agent on GitHub. It documents tasks from the Agents interface and assigning an issue to Copilot, subject to plan, repository access and policy.
Choose the target repository and base branch carefully. State the desired outcome, tests and exclusions. A cloud task can push changes; it is not merely a read-only planning conversation. Use an issue or prompt that you are ready to authorize as work.
Inspect the resulting pull request, including dependency and workflow changes. A generated summary does not prove that tests passed. Review any workflow approval request before allowing jobs with access to secrets to run. Keep follow-up implementation requests in the pull-request workflow documented for the agent.
Choose by Control and Verification Needs
- Exploration or debugging: stay in an editor session where you can inspect the local environment and steer individual steps.
- Unclear multi-file change: use a dedicated planning step, resolve open decisions, then authorize implementation separately.
- Well-defined repository task: consider the cloud-agent pull-request workflow and review the result asynchronously.
- Old Workspace bookmark or tutorial: identify it as historical. Do not buy a higher plan just to recover a preview button.
The enduring choice is how much work to delegate, where it runs and how you will verify it. None of these paths guarantees a correct implementation, so preserve version-control checkpoints and require evidence for the acceptance criteria.