Resuming a session does not restore the custom agent (regression of #917)
Chưa có ai nhận issue này.
- Ngôn ngữ chính
- Shell
- Star
- 11.2k
- Fork
- 1.9k
- Merge trung bình
- 14 giờ 16 phút
- Pull request đã merge (30 ngày)
- 6
Mô tả
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
/resumeslash command inside a running process - the
--resume=<id>flag at startup, when--agentis 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-agentthat declares one MCP server and atools:
allow-list which does not includegithub-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
/resumeand 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.
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Hướng nghiên cứu
Theo dõi các điểm vào khi khởi động của slash command /resume và --resume=<id>, sau đó kiểm tra cách bản ghi phiên được chọn và cách gợi ý resume của CLI được tạo ra. Hoàn thành khi cả hai đường dẫn resume đều giữ lại và áp dụng lại tên agent, bao gồm các máy chủ MCP và allow-list công cụ của agent, đồng thời cảnh báo nếu không thể resolve agent.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Đánh giá
- Công nghệ
- shell
- Lĩnh vực
- cli, security
- Loại issue
- Lỗi
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức độ hoạt động
- Sôi nổi
- Độ rõ ràng
- Khá rõ ràng
- Mức phù hợp với người mới
- 55/100