Resuming a session does not restore the custom agent (regression of #917)

Describe the bug

When a session is resumed, the custom agent it was started with is not restored.
Neither its mcp-servers: block nor its tools: allow-list is reapplied, so the
session silently continues as if no agent had been selected at all.

This is the behaviour reported in #917, which was closed on 2026-07-04.

It affects both ways of resuming:

the /resume slash command inside a running process
the --resume=<id> flag at startup, when --agent is not repeated

Passing --agent <name> together with --resume works correctly, so the agent
machinery itself is fine. What is missing is that the resume path does not
remember which agent the session belonged to.

Affected version

Reproduced on 1.0.82-1, 1.0.81-11 and 1.0.80 alike, so this is not a regression
of the last few builds. The behaviour appears to have been present continuously,
which suggests the fix for #917 either did not cover this path or was lost some
time ago.

Steps to reproduce

Create an agent my-agent that declares one MCP server and a tools:
allow-list which does not include github-mcp-server:

---
name: my-agent
description: repro
tools:
  - read
  - my-server/*
mcp-servers:
  my-server:
    type: stdio
    command: npx
    args: ["-y", "@playwright/mcp@latest"]
    tools: ["*"]
---
Repro agent.

Start it and note the connected servers:

copilot --agent my-agent --log-level debug

Type /resume and pick any earlier session. Alternatively, exit and run
copilot --resume=<id> without --agent.
Compare the connected servers.

Expected behavior

The resumed session runs under the same agent as before: my-server connected,
github-mcp-server suppressed by the allow-list.

Actual behavior

my-server is gone and github-mcp-server is present. The latter is the
clearest signal: it is filtered out by the agent's tools: allow-list during
normal operation, so its appearance proves the allow-list is no longer applied,
not merely the server block.

Measured on a real setup with 8 servers declared in the agent and 2 declared
globally in ~/.copilot/mcp-config.json:

how the session was resumed	`--agent` passed	servers connected
`/resume` slash command (interactive)	n/a	4
`--resume=<id>`	no	4
`--resume=<id>`	yes	12

The 4 remaining servers are exactly the globally configured ones plus the
built-in and plugin servers. Everything contributed by the agent is lost.

Server counts were read from the signature field of the MCP reconcile entries
in the debug log, not from the model's own account of its tools.

This is not #2630: the two --resume runs above both used --prompt, and the
one that passed --agent connected all agent-declared servers correctly.

Why this is worse than an inconvenience

The tools: allow-list is a safety boundary, not a convenience feature. In a
setup where it restricts a business system to read-only operations, the write
tools of that same server become available again after a resume, silently, with
no indication to the user. Anyone relying on an allow-list to keep an agent
inside a safe subset of tools loses that guarantee on resume.

There is also a visible inconsistency: the CLI prints a resume hint after every
run which omits the agent:

Resume     copilot --resume=<id>

Following the CLI's own suggestion reproduces the bug.

Possible fix

Persist the agent name in the session record and reapply it on the resume path,
the same way #917 was addressed. Where the agent cannot be resolved (renamed or
deleted), warn instead of silently falling back to no agent.

Workaround

Always repeat the agent when resuming:

copilot --agent my-agent --resume

--resume without a value opens the same session picker as the slash command,
so this keeps the normal workflow. The slash command has no equivalent
workaround.

Still present in 1.0.83-2.

Here is a cleaner reproduction than the one in the original report. This session
was started with --agent my-agent --log-level debug, so the agent was named on
the command line, and it was verifiably intact before the resume.

The MCP config signature that the runtime logs in mcp discover_and_start_root
makes the exact moment of the loss visible. User-defined servers anonymised as
server-a … server-f:

16:22:03   6 servers   server-a..f           signature_matches: false
16:22:08   6 servers   server-a..f           signature_matches: true
16:22:09   7 servers   + computer-use        signature_matches: false
16:22:09   7 servers   + computer-use        signature_matches: true   <- converged, agent intact

--- /resume at 16:25:49 ---

16:25:49   6 servers   server-a..f           signature_matches: false
16:26:06   7 servers   + github-mcp-server   signature_matches: false  <- agent definition gone
16:26:07   8 servers   + computer-use        signature_matches: false
16:26:07   8 servers   + computer-use        signature_matches: true   <- converged, agent lost

github-mcp-server is neither in the agent's mcp-servers: block nor in its
tools: allow-list. Its appearance 17 seconds after the resume is the tell: the
whole agent definition was dropped and the session fell back to the default
configuration. The very same session had converged without it minutes earlier.

Two observations that may save others some time:

The loss is not deterministic. Under 1.0.83-0 one run survived two resumes
intact, while a second run under identical conditions did not. A single clean
resume is therefore not evidence that the bug is gone.
Asking the model which tools it can see is not a reliable check. The server
set keeps moving while the reconciler converges, so a self-report is a sample,
not the state. The signature lines above are the dependable signal.

The practical impact is unchanged from the original report: an agent that
deliberately restricts a system to read-only operations silently loses that
restriction on resume, while the session still looks perfectly normal.

Correction to my previous comment: please disregard it, the reasoning was wrong.

I claimed that the appearance of github-mcp-server after the resume showed the
agent definition had been dropped. It does not. I have since established that the
CLI injects computer-use and github-mcp-server into the MCP graph by itself
after startup, in separate rounds. I observed the same injection in a run that
used no resume at all and whose agent was demonstrably intact.

The decisive evidence points the other way. At the time of that resume, the
global mcp-config.json declared eleven servers, while the agent restricted
the session to six. Both before and after the resume, exactly those six were
connected. Had the agent definition been dropped, all eleven would have come up.
It held.

So my timeline shows a normal startup sequence, not a defect. The only real
difference was ordering: before the resume the CLI had injected computer-use
but not yet github-mcp-server.

Apologies for the noise. The original report stands on its own evidence; this
comment adds nothing to it, and I would rather withdraw a wrong argument than
leave it in the thread.

For anyone else chasing this: an added server proves nothing, since the CLI
adds some on its own. The reliable signal is the opposite one, a server being
connected that the agent does not permit. That test only works while the global
configuration is broader than the agent's own set.

عدم حفظ نسخة لي بيناتي والماء تتبعيي في الأربعاء، ٢ سبتمبر ٢٠٢٦، ٧:٤٥ م Michael Vandenesch < ***@***.***> كتب:

…

*michaelvandenesch* left a comment (github/copilot-cli#4674) <#4674 (comment)> Correction to my previous comment: *please disregard it, the reasoning was wrong.* I claimed that the appearance of github-mcp-server after the resume showed the agent definition had been dropped. It does not. I have since established that the CLI injects computer-use and github-mcp-server into the MCP graph by itself after startup, in separate rounds. I observed the same injection in a run that used no resume at all and whose agent was demonstrably intact. The decisive evidence points the other way. At the time of that resume, the global mcp-config.json declared *eleven* servers, while the agent restricted the session to *six*. Both before and after the resume, exactly those six were connected. Had the agent definition been dropped, all eleven would have come up. It held. So my timeline shows a normal startup sequence, not a defect. The only real difference was ordering: before the resume the CLI had injected computer-use but not yet github-mcp-server. Apologies for the noise. The original report stands on its own evidence; this comment adds nothing to it, and I would rather withdraw a wrong argument than leave it in the thread. For anyone else chasing this: an *added* server proves nothing, since the CLI adds some on its own. The reliable signal is the opposite one, a server being connected that the agent does not permit. That test only works while the global configuration is broader than the agent's own set. — Reply to this email directly, view it on GitHub <#4674?email_source=notifications&email_token=CJDXT5PLGSXIJDUPGWQTQVT5NBFDVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJRGMYDOMJWGY32M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-5513071667>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CJDXT5ONYOELHK6SP4TWEDD5NBFDVAVCNFSNUABFKJSXA33TNF2G64TZHM2TQNJYGYYDMNRUHNEXG43VMU5TKMRZG42TOMBVHAZKC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CJDXT5L5MQQXCGBMWVGTTGD5NBFDVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJRGMYDOMJWGY32M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/CJDXT5OISSENDMGVFFPYH335NBFDVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJRGMYDOMJWGY32M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

Navigation Menu

Repository navigation

Resuming a session does not restore the custom agent (regression of #917) #4674

Describe the bug

Affected version

Steps to reproduce

Expected behavior

Actual behavior

Why this is worse than an inconvenience

Possible fix

Workaround

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Resuming a session does not restore the custom agent (regression of #917) #4674

Description

Describe the bug

Affected version

Steps to reproduce

Expected behavior

Actual behavior

Why this is worse than an inconvenience

Possible fix

Workaround

Activity

michaelvandenesch commented on Sep 2, 2026

michaelvandenesch commented on Sep 2, 2026

anahagaer877-coder commented on Sep 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions