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

[michaelvandenesch]

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

1. 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.

2. Start it and note the connected servers:

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

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

4. 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.