Copilot Subconscious sidekick keeps spawning per-prompt even with memory disabled (/memory off, settings memory:false)

[carlosmayol]

Summary

The Copilot Subconscious background sidekick (the per-prompt memory "voting" agent, internal flag copilot_cli_subconscious) keeps spawning on every user prompt even when Copilot Memory is fully disabled — both via /memory off and settings.json "memory": false. It should not run at all when memory is off.

This is new behavior that appeared in a recent release. It adds a background session per prompt, fires vote_memory/inbox activity, and (when an extension registers an onUserPromptSubmitted hook) the sidekick session re-runs that hook and its output bleeds into the single interactive terminal — producing a visible duplicate of the extension's hook output on every turn. It also intermittently makes the input line feel frozen while the extra background turn runs.

Environment

• Copilot CLI 1.0.64-0 (win32-x64), Windows 11, PowerShell 7.
• ~/.copilot/settings.json: "memory": false, "experimental": true.
• /memory show → Status: disabled (via /memory off).

Steps to reproduce

1. Run /memory off and confirm /memory show reports disabled.
2. (Optionally) also set "memory": false in ~/.copilot/settings.json.
3. Start a session and send any normal prompt.
4. Open /sidekicks.

Expected: No memory/Subconscious sidekicks run, because memory is disabled.

Actual: /sidekicks lists multiple Copilot Subconscious [background] entries — one per prompt. The session event log shows a parallel sidekick-subconscious-agent-<timestamp> session mirroring each prompt ("Current user request: …"), running the same prompt hooks, and emitting send_inbox / vote_memory activity. Inbox from Copilot Subconscious notifications keep arriving.

Why this is a regression

/memory off is documented as persistent (added 1.0.49) and the store/retrieve memory tools are gated on the memory-enabled state ("The store_memory tool is only included when memory is enabled for the user", 0.0.385). The Subconscious / vote_memory sidekick path is not honoring that same disabled state — it spawns regardless. Recent memory-area changes (e.g. vote_memory throttling in 1.0.55, SDK session-memory config in 1.0.62) suggest this path is gated by the server-pushed experimental flight (copilot_cli_subconscious, availability team) independent of the user's /memory setting.

Expected fix

When memory is disabled for the user (via /memory off or settings.memory: false), the Subconscious background sidekick (copilot_cli_subconscious) must not spawn, regardless of the server experimental flight assignment. The user-facing memory toggle should be the authoritative off switch.

Current workaround (for others hitting this)

Set the env override the CLI itself uses, at user scope, then restart:

COPILOT_EXP_COPILOT_CLI_SUBCONSCIOUS=false

(The resolver isCopilotSubconsciousEnabled() honors COPILOT_EXP_<FLAG> overrides; the CLI sets this same var to true when spawning the detached rem-agent.) /memory off alone does not stop it.

Additional note

Every release seems to flip or introduce a new default in this area (experimental gate resetting, memory sidekick spawning). A single, authoritative, user-respecting off switch for memory — that the per-prompt Subconscious also obeys — would prevent this recurring breakage.

[carlosmayol]

Clarifying the root cause — this is one feature with two halves, and only one obeys the switch.

After reading the CLI bundle (app.js, 1.0.64-0), the "Copilot Subconscious" sidekick is the write/consolidation half of Copilot Memory: a background rem-agent whose job is to vote on and store memories (vote_memory) into the dynamic context board so future sessions benefit (/subconscious run = "Store current trajectory learnings for future sessions").

So Memory really has two halves:

• Retrieval (read): injects past memories into the prompt — this is what /memory off controls today.
• Subconscious (write): the per-prompt background voting/consolidation agent — gated by the separate experimental flight copilot_cli_subconscious (availability team), which /memory off does not touch.

That split is the bug: if a user has turned Memory off, they have unambiguously opted out of Memory — including its write side. The Subconscious storing/voting on memories while the user believes Memory is disabled is both surprising and a privacy concern (it's consolidating conversation content into a store the user thinks they disabled).

Expected: /memory off (and settings.memory: false) is the single authoritative kill switch for the entire Memory feature — retrieval and the Subconscious write path. The copilot_cli_subconscious flight should be subordinate to the user's memory setting, never override it.

(Workaround confirmed working on Windows 1.0.64-0: setting COPILOT_EXP_COPILOT_CLI_SUBCONSCIOUS=false at user scope and restarting → /sidekicks shows No sidekicks. But that's an internal env override; the user-facing /memory off should have done this.)

[szabta89]

Thanks for reporting this.

We re-tested the reported behavior and confirmed it is resolved in GitHub Copilot CLI 1.0.78.

I'm closing this issue as completed. If you still encounter the problem on that version or newer, please share updated reproduction steps and we can take another look.