Feature request: repo-level memory so AI agents keep context across sessions and tools

[Kaushalt2004]

🏷️ Discussion Type

Product Feedback

Body

The problem

When I work on a repo with AI agents (Copilot, Claude Code, Codex), every new session starts from zero. The agent doesn't know:

• what was changed in the last session and why
• which decisions were made (and the reasons behind them)
• which tasks were left open
• exact values like ticket IDs, versions, ports, branch names

So I re-explain the project every morning, and agents sometimes undo a fix from two days ago because they don't know why it was made.

copilot-instructions.md / CLAUDE.md help, but they have to be updated by hand, they keep growing, and they don't capture session-level state.

What I'd like GitHub to consider

A small, structured "handoff" stored per repository that any agent can read and write:

• Goal, current state, decisions (with why), open tasks, key values
• Written automatically at the end of an agent session (Copilot coding agent, or via MCP)
• Read automatically at the start of the next one, as a short brief rather than full history
• Visible and editable by the repo owner, nothing secret stored

Since GitHub already sits between all these agents, the repo is the natural place for this memory to live.

What I do today

I built an open-source workaround for myself, CogniCore (Apache 2.0): https://github.com/cognicore-dev/cognicore-env. It uses Claude Code / Codex hooks to save a short handoff after each session and exposes it over MCP, so Claude.ai, ChatGPT and Cursor can read it too. It works, but native support in GitHub would be far better for everyone.

Questions for others

How do you keep context between agent sessions on the same repo? Notes file, issues, something else?

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[SebastiaanBoon]

What has worked for me on the "agent undoes a fix from two days ago" problem is to keep the reason next to the code, not only in a session brief.

1. A HANDOFF.md in the repo root, rewritten (not appended) at the end of each session, under 40 lines: goal, current state, open tasks, key values (ports, branch, versions). Ask the agent to write it as the last step and to read it first in the next session.
2. A separate DECISIONS.md that is append-only, one entry per decision: date, what, why, and what was rejected. The "why" is the part agents need to stop reverting things.
3. For a fix that looks wrong on its own, a one-line code comment with the reason and the issue or commit id. An agent that reads the file sees the warning exactly where it is tempted to change it.
4. Point CLAUDE.md or copilot-instructions.md at those two files with a load rule, and keep that file to stable rules only. It stays short because the changing state lives elsewhere.

That covers one repo. The part that does not fit in a repo is what follows you across repos and chats: your own rules, preferences and work history. I built Cloud Alter Ego for that layer. It is a remote MCP connector that serves those as plain Markdown files from your own cloud storage, so Claude.ai, ChatGPT and agents can all read the same files. It does not replace a per-repo handoff. Docs: https://cloudalterego.cafeboon.com/docs.html

[Kaushalt2004]

But does it work in realtime like if i save something on claude-code which is local and want the data in claude.ai or codex in less then a second can i get it and it should be bidirectional

[SebastiaanBoon]

Not at the speed you describe, I can't promise that. With Cloud Alter Ego the connector reads and writes the files directly in your own storage (for example a Git repo) on each call, so a chat that has the connector sees what another chat wrote on its next read, without a separate sync step. A local Claude Code only joins in if it also has the connector or uses the same repo. I haven't measured latency, so I won't give you a number.

[100rootrain]

Part of this already exists, but each vendor keeps it to itself. I think that's the real gap to ask GitHub about:

• Copilot Memory stores repository-level facts with citations to the code that supports them. It checks those citations against the current branch before using a fact, expires facts (90 days by default), and lets people with write access review and delete them in the repository settings. It's shared across Copilot surfaces (cloud agent, CLI, code review), but other agents can't read it. (docs)
• Claude Code auto memory is per repository too, but it's machine-local (~/.claude/projects/<project>/memory/) and not shared across machines. (docs)

So the ask could be narrower than a new feature: expose Copilot Memory's repository facts, with the same citations and expiry, through the GitHub API or MCP server, so any agent can read and write the same store.

What works for me today, without extra tooling:

1. One instruction file for every agent: AGENTS.md. Codex and Copilot read it, and Claude Code reads it when there's no CLAUDE.md (or you add @AGENTS.md to your CLAUDE.md). I keep only stable rules there.
2. Session state on the pull request, not in a file. The draft PR description holds the goal, current state, open tasks as checkboxes, and key values; decisions go in PR comments. That avoids two problems with a committed handoff file: parallel branches rewriting the same file and conflicting, and state that only syncs on push/pull. Any agent with GitHub access (the GitHub MCP server in Claude.ai, ChatGPT, Cursor, etc.) reads and updates the same PR. For work without a PR, an issue does the same job.
3. For "the agent undid my fix": a regression test. It's the one memory an agent can't skip, because it runs the tests. Put the why in the commit message, and add a rule to AGENTS.md such as: "Before changing code that looks wrong, run git log -L <start>,<end>:<file> and read the commit message."

On the real-time question above: a file in the repo only syncs on push/pull, so it can't be sub-second. A PR or issue is visible to every tool on its next read, with no sync layer to run. None of these push changes into a session that's already running, though; the agent has to re-read.

[Kaushalt2004]

Expose Copilot Memory's repository facts (with the same citations, branch validation and expiry) through the GitHub API / MCP server, so any agent can read and write the same store

The citation check against the current branch is exactly the piece that's hard to build outside GitHub. Facts that verify themselves against the code are much safer than a summary that slowly goes stale. Opening that up would solve most of what I described.

Your PR-as-session-state approach is clever, and I hadn't thought about parallel branches fighting over a committed handoff file. That's a real problem. The regression-test point is also fair: a test is the one memory an agent can't ignore. I'm adding the git log -L rule to my AGENTS.md today.

Where I still see a gap, and why I built my own workaround:

• Capture is manual The PR description only stays current if the agent (or I) remember to update it. In practice the useful context is in the session, and it's gone when the session ends unless something saves it automatically. Hooks can do that; a PR can't on its own.
• Not all work has a repo or PR Planning in Claude.ai on my phone, research or debugging before a branch exists: none of that has a natural home on GitHub.
• Still per vendor Even if Copilot Memory is exposed, Claude Code's auto memory stays machine-local, so there are still two stores.

That's the part CogniCore tries to cover (hooks save a short handoff after each Claude Code / Codex turn, readable over MCP), but honestly, if GitHub opened Copilot Memory through MCP, I'd rather build on top of that than keep a separate store.

Would you be up for opening that narrower request as its own discussion, or should I edit this one? I think it'd get more support framed your way.