Subagent Tried to Call `store_memory` And Failed. Should They Have Had the Tool?

[rolledback]

Describe the bug

Looked like this:

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

Affected version

0.0.394

Steps to reproduce the behavior

No response

Expected behavior

No response

Additional context

No response

[ericchansen]

I've been noticing this for the last couple weeks too. See #1751.

[NlightNFotis]

@ericchansen @rolledback Thanks both for the report.

Would one of you be able to share the repositories for which you're seeing these issues?

[ericchansen]

@NlightNFotis, sure! Here's a Copilot generated table of when it was able to find recent interactions with memories. I think there are more examples than what it was able to find. To me, it seems like it hasn't worked anywhere for a week or so.

Date (UTC)	Result	Repo	What Happened
Feb 5 04:24	✅ Success	ericchansen/itemwise	Stored "always use feature branches for CI/CD"
Feb 6 01:33	✅ Success	ericchansen/webstore	Stored "Use Microsoft Edge, not Chrome"
Feb 10 22:41	✅ Success	ericchansen/itemwise	Stored "verify before returning prompt" rule
Feb 12 20:55	✅ Success	ericchansen/teamskills	Stored "review locally before push"
Feb 17 18:27	✅ Success	ericchansen/msx-mcp	Stored safety measures — last confirmed success
Feb 19 01:38	⚠️ Stored then crashed	ericchansen/teamskills	"Memory stored: staging deployment" appeared, then server errored 5x and execution failed
Feb 19 18:07	⚠️ Screenshot of same	ericchansen/itemwise	"Memory stored" ✓ followed by server crash
Feb 26 18:13	❌ Failed	ericchansen/teamskills	"Memory storage appears to be down entirely" — first outright failure
Mar 1 19:19	❌ Failed (2x)	ericchansen/teamskills	Both returned "Unable to store memory"
Mar 1 19:28	📋 Bug filed	ericchansen/teamskills	Filed #1751
Mar 2 00:50	❌ Failed (silent)	ericchansen/itemwise	Agent claimed stored but checkpoint noted "NOT DONE"
Mar 2 04:24	❌ Failed	ericchansen/teamskills	Failure visible in CLI output (screenshot)

Summary:

• Last known success: Feb 17 (ericchansen/msx-mcp)
• Transitional: Feb 19 — writes succeeded but model server crashed immediately after
• Confirmed broken since: Feb 26 — every attempt fails across all repos
• Reads still work — existing <repository_memories> load at session start, only writes broken
• Affected repos: ericchansen/teamskills, ericchansen/itemwise, ericchansen/msx-mcp, ericchansen/webstore
• CLI version: 0.0.420 (current)
• OS: Windows 11
• Model: Claude Opus 4.6

[adityasharad]

Thank you @ericchansen - could you share how you're authenticated to the CLI, and what scopes you've granted the token? Looking at our internal logs we suspect the problem is insufficient permissions granted to the token for those recent runs.

[ericchansen]

I'm going to close this as stale. Recently, this has started working. I have no idea why, but I'll take what I can get.

If you'd like to follow up on this, I can dig through my Copilot CLI session histories to probably get you some more info.

Okay, I can't actually close these. Just let me know if you really want more info.

[ericchansen]

@adityasharad — here's the auth info you asked for:

Authentication:

• Method: gh auth login via browser OAuth flow (keyring-stored token)
• Token prefix: gho_**** (OAuth token, not PAT)
• Token scopes: admin:public_key, gist, read:org, repo
• Protocol: SSH for git operations
• CLI version: 1.0.4-0 (latest)
• Active account: ericchansen (personal, not EMU)

Update on the "working again" comment from earlier today:

I commented ~2 hours ago that it had started working again. That was premature — it just failed again in the same session. Three consecutive store_memory calls, all returned "Unable to store memory." So it appears to be intermittent, not fixed.

Timeline update:

Date	Result	Version	Repo	Notes
Feb 17	✅ Last confirmed success	0.0.4xx	ericchansen/msx-mcp	—
Feb 19	⚠️ Wrote then crashed	0.0.4xx	ericchansen/teamskills	Server errored 5x after write
Feb 26 – Mar 9	❌ Consistent failure	0.0.420	multiple repos	Every attempt fails
Mar 10 ~16:00	✅ Working (reads loaded 15+ facts)	1.0.4-0	ericchansen/wingman	Reads worked at session start
Mar 10 ~18:03	❌ Failed (3x in one turn)	1.0.4-0	ericchansen/wingman	Same session, same auth

Key observations:

1. Reading always works — <repository_memories> loads stored facts every session
2. Writing is intermittent — sometimes works, sometimes silently fails
3. No local config changes between working/failing states
4. All other API-dependent tools work fine in the same session (gh CLI, task agents, SQL, LSP, MCP servers)
5. The token scopes haven't changed since the period when it WAS working

If insufficient permissions are the suspected cause, what additional scope would store_memory need? The current scopes (admin:public_key, gist, read:org, repo) seem complete for a standard OAuth flow. Happy to test with a different scope set if you can tell me what's expected.