GitHub introduced Copilot Dreaming in public preview on October 28, 2026, alongside the general availability of Copilot Memory. Dreaming uses earlier sessions and review feedback to maintain the context that guides later work. For security teams, the important change is that some of that guidance can change without a pull request.
Reviewing instruction-file diffs leaves other changes unchecked. GitHub's Dreaming documentation says memories can change automatically, as can internal guidance used by Copilot code review. Turning Dreaming off does not reverse those changes.
Before enabling the preview, identify which repositories and users it will cover, which outputs a reviewer can inspect, and how the team will recover from incorrect guidance. The procedure below is our recommendation based on the documented controls. We have not tested a live Dreaming deployment.
Separate the outputs that need review#
GitHub documents three different change paths. A repository's PR queue does not contain all of them.
| Output | How the change takes effect | Review responsibility |
|---|---|---|
| Personal or repository memories | Dreaming adds, changes, or deletes them automatically. | Inspect available memory changes and remove incorrect stored guidance. |
| Checked-in instructions and skills | Dreaming proposes a PR; files change when it merges. | Review the diff and preserve the repository's required approvals. |
| Internal code-review guidance | Dreaming updates it without a PR, using feedback on merged PRs and current code. | Assess subsequent reviews against independently maintained requirements; do not count the file-review process as coverage. |
Source: GitHub's output and approval rules. The last column is our recommended review assignment.
For a hypothetical example, a team repeatedly accepts feedback that a slow test is unnecessary for a narrow class of changes. Background maintenance could turn that feedback into reusable guidance. The reviewer needs to check its scope: a test exception for documentation changes should not become a reason to skip the same test when an authorization handler changes. This is an illustrative review case, not a vulnerability we reproduced.
Keep mandatory checks in the repository's enforced merge requirements. GitHub explicitly warns that neither memories nor custom instructions guarantee compliance. Operation permissions and sandbox restrictions also remain separate; our managed-permissions guide covers those controls.
See how your AI systems hold up under real attacks
General Analysis maps AI applications and agents, red teams prompts, retrieval, tools, MCP servers, browser actions, permissions, and business workflows, then turns findings into evidence your team can reproduce and retest.
Limit repository access before enabling Dreaming#
Start with an organization and a small, named repository set. In the organization's Settings → Copilot → Policies, review Memory → Repository access before setting Dreaming to Enabled. GitHub's administration guide says Dreaming covers the current Copilot Memory repository selection. The repository-access default is All repositories.
At enterprise level, use AI controls → Copilot → Configure features & clients. Let organizations decide permits an organization pilot. Check the starting state before treating delegation as a restriction: changing from Enabled everywhere to Let organizations decide leaves Dreaming enabled in the organizations that already inherited it. Organization owners can then disable it; the enterprise change does not do that for them.
Record the actual repository selection and organization state in the rollout approval. Personal Dreaming needs its own user enablement and remains subject to managed policy. A personal opt-out does not stop organization-owned repository runs.
Also check the preview's availability and prerequisites. It requires an eligible paid subscription and access to GPT-6.1 Sol, excludes Copilot Pro, and does not support GitHub Enterprise Cloud with data residency. Memory being generally available does not establish Dreaming eligibility.
Repository customization and personal memory curation require session syncing. For managed users, Store local sessions in the Cloud must permit at least View from cloud. Approve that data movement before enabling it. Code-review customization does not require session syncing; it instead requires Copilot code review and its preview features, and currently excludes self-hosted runners.
A repository Dreaming setting can enable both repository customization and code-review customization. GitHub does not provide independent switches for those capabilities. If prerequisites are completed after Dreaming is already enabled, its documentation instructs administrators to turn the affected setting off and on again. Review that reactivation because it may enable another capability.
Inspect the run, then inspect the resulting work#
GitHub.com holds the settings; individual run outputs appear in the Copilot app. Add the pilot repository to the app, then open Automations → Dreaming. Under Repository Dream runs or Personal Dream runs, inspect the status, available summary, warnings, and memory changes. Updated memories can show before-and-after text when available. Follow any PR link to review the proposed file changes. These steps follow GitHub's run-review procedure.
Save the observed scope and time with each review. A completed run without a PR may still have changed memories or review guidance. An empty run list immediately after enablement also needs care: GitHub schedules runs, and the app's refresh button only reloads the list. Administrators cannot manually start runs or edit their schedules, prompts, or model.
Correlate the available run details with the Copilot Memory audit log. For repository memory creation, GitHub documents the search action:copilot.memory_created repo:ORG/REPO. Creation and deletion events contain actor and time metadata, but no memory text, citations, or explanation. Retrieval, voting, and automatic expiry do not generate memory lifecycle events. Keep the inspected content separately; this log cannot reconstruct every context change.
Check instruction and skill diffs for changes to test coverage, exceptions, and permitted destinations. Dreaming can review tracked files including AGENTS.md, CLAUDE.md, .github/copilot-instructions.md, and .github/skills/**; the effect of merging a change depends on which agents consume that file.
For the pilot, compare subsequent Copilot reviews with a small set of known requirements maintained by the team. Record omissions and incorrect assumptions, and require human review of consequential changes. A successful review run cannot establish that an earlier vulnerability was fixed; use the original scanner and reviewed revision for that decision.
Budget for runs that produce no changes. GitHub documents AI-credit use for every Dreaming run, including inactive repositories. Check the relevant billing account's spending controls before widening the repository set; an alert alone does not stop usage.
Disable future runs and reconcile earlier changes#
Use the documented shutdown controls for the affected scope. At enterprise level, Disabled everywhere prevents organizations from enabling Dreaming. At organization level, disable it in the applicable policy. Removing a repository from the Copilot Memory selection disables both Memory and Dreaming for that repository, so assess that broader effect before choosing it as the containment action.
A run already in progress may continue. Capture its status and inspect its final outputs if available. Disabling Dreaming neither closes its PRs nor deletes its memories, restores removed memories, or reverts merged files. Ordinary Copilot interactions can also create memories while Dreaming is off.
Reconcile each output separately:
- Review open instruction and skill PRs; close unwanted proposals. Revert already-merged changes through the normal repository review process.
- Inspect stored personal preferences and repository facts, preserving necessary evidence before deleting incorrect entries. GitHub's personal-memory instructions recommend reviewing and deleting preferences before turning that feature off.
- Treat internal code-review guidance as a separate unresolved item when it cannot be inspected or restored. The cited documentation gives no run-level undo control or restoration procedure for that guidance. Keep required human review and independent checks in place; seek a supported recovery path before claiming a full rollback.
- Check sessions that already received the affected context. In the CLI,
/memory offstops further storage and retrieval, but existing conversation context can retain supplied memories. GitHub instructs users to start a new session to continue without that earlier context.
Turning off session syncing also leaves previously synced sessions intact. Handle any deletion request through the applicable session-data controls; neither stopping sync nor stopping Dreaming is evidence that retained content was erased.
Plan who can perform the memory review before changing its settings. GitHub's repository-fact management procedure requires write access and enabled user-level preferences to view or delete facts in the repository settings page. Agent access to those facts follows separate repository and client controls.
Keep a recovery record that distinguishes observed completion from unknown state. This illustrative JSON is an internal checklist shape, not a GitHub API response or an executed result:
Code source: illustrative.
{
"repository": "EXAMPLE/security-pilot",
"observed_at": null,
"future_runs_disabled": null,
"in_progress_run_reconciled": null,
"memory_changes_reviewed": null,
"instruction_prs_reviewed": null,
"internal_review_guidance_recovery": "unverified",
"affected_sessions_restarted": null,
"evidence_locations": []
}
Fill the record from actual observations and restrict access to any saved memory or session text. GitHub says app run details are not a complete activity history. Missing before-and-after text must remain missing evidence, rather than an assumed unchanged value.
Expand the pilot only when the team can account for the automatic outputs and accepts the documented recovery limits. If policy requires a person to approve every change to agent guidance before use, the automatic memory and internal-review paths do not satisfy that requirement. Keep Dreaming disabled for that scope and retain the broader coding-agent security controls.
Frequently asked questions
- Does every Copilot Dreaming change need a pull request?
No. Changes to checked-in instructions and skills are proposed in pull requests. Dreaming can add, update, or delete memories automatically and update internal code-review guidance without a pull request.
- Does disabling Copilot Dreaming undo its changes?
No. It stops future runs within the setting's scope, while a run already in progress may continue. Existing memories, instruction pull requests, and earlier changes need separate review. The app has no run-level undo option.
- Can repository customization and code-review customization be enabled separately?
GitHub's preview documentation says a Dreaming setting enables the capabilities whose prerequisites are met within its scope. Repository customization and code-review customization cannot be switched on or off individually.
