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.)