Repository navigation
GitHub Copilot Memory facts are not injected into the system message on session.create (only on session.resume) #1562
Description
Activity
Investigation Findings
Thanks for the detailed report. I investigated the relevant SDK code paths and the JSON-RPC layer.
What I looked at
nodejs/src/client.ts—createSession()(line 1018) andresumeSession()(line 1225) implementationsnodejs/src/types.ts—SessionConfigtype, includingskipEmbeddingRetrievalandembeddingCacheStoragenodejs/src/generated/rpc.ts— wire-level parameter types forsession.createandsession.resume
What I found
The SDK faithfully proxies both calls to the Copilot CLI via JSON-RPC (
session.createandsession.resumerespectively). The decision of when to inject memory facts into the system message is entirely CLI-side behavior.Key observations:
session.createaccepts askipEmbeddingRetrievalparameter (exposed in the SDK asconfig.skipEmbeddingRetrieval), confirming the CLI can load memory/embeddings on fresh sessions — but this controls embedding retrieval, not long-term memory fact injection.- There is no SDK-level flag to request eager memory loading on
session.create. - The fact that
session.resumetriggers memory injection whilesession.createdoes not is an asymmetry that appears unintentional — the CLI is presumably loading persisted session context (including memory facts) as part of the resume path, but not seeding them on fresh sessions. - The workaround you described (create → wait for
session.tools_updated→ disconnect → resume same ID) proves the CLI has the capability; it's just not triggered for fresh sessions.
Verdict: Bug
Memory facts should be available on turn 1 of a fresh session for any repo that has stored facts — the current behavior makes long-term memory unusable in short-lived CLI/CI workflows. The discrepancy between
createSessionandresumeSessionappears to be an unintentional gap in the CLI's memory-loading logic, not a deliberate design choice. Labeled accordingly.A proper fix would be for the CLI to apply the same memory injection logic to
session.createas it does tosession.resume. An optional SDK-level config flag (e.g.eagerMemoryLoad: true) could serve as an interim API while the fix is implemented.Generated by Bug Handler for issue #1562 · ● 3.5M · ◷
Reacted by MUHAMMAD AMILIN BIN HASANANWe don't have formal support for memory in the SDK, but some work is being done on this front. Relabeled as an enhancement while we look at getting it out.
Closing as fixed after verification against the current public SDK sources and bundled behavior.
Public evidence
- #1617 — SDK: add optional memory configuration to session create and resume (merged 2026-06-15)
- commit
86df7e50f064— SDK: add optional memory configuration to session create and resume (SDK: add optional memory configuration to session create and resume #1617) nodejs/src/types.ts—MemoryConfiguration; memorynodejs/src/client.ts—createSession; resumeSession; memorynodejs/test/client.test.ts—forwards memory configuration in session.create request; forwards memory configuration in session.resume request
The reported behavior/request is implemented at the current SDK baseline, so this issue is being closed as completed.
Public SDK baseline: github/copilot-sdk
d5c9d06d8c41.
Package: @github/copilot-sdk
Summary
Memory facts stored for a repo are embedded inline into the first turn's
system message when a session is started via
client.resumeSession(), butNOT when started via
client.createSession(). There is no public SDK APIto query stored memory facts or to opt memory injection into a new session.
Repro
client.createSession(config).system.messageevent content — facts are absent.client.resumeSession(existingId, config)on a different existing session for the same repo.
system.messagecontent now includes a memory block (~13KB deltain our case: 35,090 chars vs 48,213 chars).
Expected
One of:
(a) Memory facts injected on
createSessiontoo.(b) An explicit config flag (e.g.
eagerMemoryLoad: true) to opt in.(c) Public docs describing exactly when memory injection happens so
consumers can build supported workarounds.
Current workaround
createSession → wait for
session.tools_updated→ disconnect →resumeSessionon the same ID. Works but adds an extra RPC round-tripand depends on the resume side-effect behavior continuing as-is.
Why this matters
Users with
--new-sessionsemantics still expect their stored memoryfacts to be available on turn 1. Otherwise memory is unusable in
short-lived CLI/CI runs.