store_memory consistently fails with 'Unable to store memory' since ~Feb 13

[ericchansen]

Bug: store_memory consistently returns "Unable to store memory"

Environment

• Copilot CLI version: 0.0.420
• OS: Windows 11
• Model: Claude Opus 4.6

Description

The store_memory tool consistently fails with: "Unable to store memory. You can continue with your task without storing this information."

Reading previously stored memories works fine - the <repository_memories> section loads 15+ facts at session start. Only writing new memories fails.

Timeline

Timeframe	Result
Early Feb 2026	Success (multiple repos)
Mid Feb 2026	Last known success
Late Feb 2026	Failed
Mar 1, 2026	Failed (4+ attempts across 2 sessions)

What I've verified

• No local config issue (no memory-related settings in ~/.copilot/config.json)
• No local storage issue (memories are server-side, not in session-store.db)
• All other API-dependent tools work (gh CLI, task agents, SQL, LSP)
• Authentication is working
• CLI is current version (0.0.420)

Expected behavior

store_memory should persist facts to the repository-scoped memory store, returning a success confirmation.

Actual behavior

Every call returns "Unable to store memory. You can continue with your task without storing this information." with no additional error detail.

Impact

Without working memory storage, the agent cannot learn from mistakes across sessions. This means:

• Important conventions must be re-explained each session
• Bug patterns that should be remembered get forgotten
• User preferences don't persist unless manually added to instruction files

Related issues

• Subagent Tried to Call store_memory And Failed. Should They Have Had the Tool? #1108 - Subagent store_memory failures (similar symptom, different context)

[ericchansen]

Closing in favor of #1108.

[ericchansen]

Still reproducing as of 2026-03-10 (v1.0.4-0, Claude Opus 4.6)

store_memory is still failing. Three consecutive calls in one turn, all returned:

Unable to store memory. You can continue with your task without storing this information.

Context of this occurrence:

• Repository: ericchansen/wingman (same repo as original report)
• Session: Active session with full tool access — all other tools working (gh CLI, SQL, LSP, task agents, Chrome DevTools, etc.)
• Trigger: Attempted to store 3 testing-practice facts after a user feedback conversation
• All 3 calls had valid parameters — category, fact, citations, reason, subject all provided
• Reading works — <repository_memories> loaded 15+ facts at session start from prior successful stores

Example call that failed:

{
  "category": "user_preferences",
  "subject": "testing practices",
  "fact": "When testing user-facing features: open the actual URL in the browser, follow printed instructions literally, never substitute API checks for visual verification.",
  "citations": "User input: direct feedback about missed bugs",
  "reason": "Failed to catch EADDRINUSE crash and 'Cannot GET /' error because I tested API endpoints instead of opening the browser like a real user."
}

This suggests the issue was not actually fixed when this was closed on 2026-03-01. The write endpoint appears to be intermittently or consistently rejecting store_memory calls.

[ericchansen]

Comprehensive update — intermittent, not fixed (2026-03-10)

Updating with more research and data. This issue should be reopened.

Latest failure (today, ~18:03 UTC):
Three consecutive store_memory calls failed in the same session where <repository_memories> successfully loaded 15+ stored facts at session start. All other tools (gh CLI, SQL, task agents, LSP, Chrome DevTools, MCP servers) worked perfectly in the same session.

Auth details (per @adityasharad's request on #1108):

• Token: gho_**** (OAuth via gh auth login browser flow, keyring-stored)
• Scopes: admin:public_key, gist, read:org, repo
• CLI version: 1.0.4-0
• Account: ericchansen (personal, not EMU)
• These scopes are unchanged from when store_memory was working (Feb 5–17)

Pattern analysis across all data points:

Phase	Dates	Behavior
Working	Feb 5 – Feb 17	Consistent success across 5+ repos
Transitional	Feb 19	Writes succeeded but model server crashed immediately after
Broken	Feb 26 – Mar 9	Every write fails, reads always work
Intermittent	Mar 10	Reads work, writes sometimes work briefly then fail again in same session

Community impact:

• Issue Subagent Tried to Call store_memory And Failed. Should They Have Had the Tool? #1108 (open, 3 👍) reports the same symptom from subagents (v0.0.394)
• Web search confirms widespread reports — described as "server-side issue with no client-side fix"
• HostingSeekers listed it as a top Copilot error for 2026
• No known workaround exists

What would help:

1. What scope/permission does store_memory require? Is it a Copilot-specific API scope not covered by standard repo?
2. Is there a way to get more detailed error info from the tool? Currently it returns only "Unable to store memory" with zero diagnostics.
3. Is the memory write endpoint rate-limited, quota-limited, or behind a feature flag that may have changed?

Cross-ref: #1108 (replied with auth details there too)