Repository navigation
--agent <name> selection is dropped ~1s after startup (race with sign-in / MCP reload) #5124
Description
Describe the bug
When starting the CLI with --agent <name>, the custom agent is selected and then silently deselected ~1 s later, before any user input. The banner shows Selected custom agent: my-agent, then MCP Servers reloaded: 1 server connected, and the agent disappears from the status bar; the session falls back to the default agent.
It looks like a race between the startup agent selection and the agent/MCP refresh after sign-in. events.jsonl of an affected session (no user input in between):
14:59:11.603 subagent.selected {"agentName":"my-agent"}
14:59:11.765 subagent.selected {"agentName":"my-agent"}
14:59:11.717 subagent.selected {"agentName":"my-agent"} <- out of order, concurrent re-selection
14:59:12.400 subagent.deselected {}
The deselect follows Signed in to https://github.com and the MCP client re-init in the process log (Service initialized as client -> task cancelled -> Service initialized as client).
Affected version
1.0.95
Steps to reproduce the behavior
- Have a custom agent available (user-level
~/.copilot/agents/my-agent.md, or plugin-provided). - Start interactively:
copilot --agent my-agent - Don't type anything; watch the banner and status bar for ~2 s.
- Agent is gone from the status bar;
events.jsonlshowssubagent.deselected.
Expected behavior
The agent passed via --agent stays selected for the whole session.
Additional context
- Frequency (automated pty launches, no input, 15 s each): dropped 5/6 with a user-level agent (
--agent my-agent), 4/6 with a plugin agent (--agent myplugin:my-agent). - When MCP startup failed (
Failed to start MCP Servers: session not found), the agent was never dropped, which points to the MCP reload / agent-list refresh path clearing the selection. - Workaround: run
/agent my-agentafter startup. - macOS (Apple Silicon, arm64), zsh, launched via shell alias with
--allow-alland several--deny-toolflags.
Activity
jonathan-vella commentedon Oct 20, 2026
Reproduced in the GitHub Copilot App (Windows,
copilotVersion1.0.99-2) with a plugin agent (upgrade-agent:upgrade, frommicrosoft/upgrade-agent-plugins1.1.685). 9/9 sessions dropped the agent, including sessions created by the app UI and bycreate_sessionwith a kickoff agent. It happens before the first user message.After the deselect the system prompt is the generic default one and the agent's MCP tools (
Upgrade/*) are never attached, so the agent's workflow cannot run. Nothing is shown to the user.Ruled out (controlled runs, same project and prompt) - the agent is still dropped when:
mcp-serversblock is removed entirelydnx)session.permissions_changedis then absent, but the deselect still happens)Supports the race hypothesis in this issue: the one session that kept the agent was blocked on a pending extension
permission.requested("register hooks") during startup and never completed it until the session was aborted. Startup stalled -> no deselect. This matches "when MCP startup failed, the agent was never dropped", i.e. the post-create refresh path clears the selection.So the app is affected as well as the CLI. Selecting a plugin agent as the session agent at creation is currently not reliable there; the app has no equivalent of the
/agent <name>workaround at startup.Side finding, separate from this bug: the app host's YAML parser rejects
agents/upgrade.agent.md("flow content must be indented more than the surrounding block", closing]of a multi-lineargs: [...]at the same indent asargs:); PyYAML and the JSyamlpackage accept it. I'll report that on the plugin repo.jonathan-vella commentedon Oct 20, 2026
Correction to my comment above: the real variable was folder trust, not the stalled permission prompt.
config.json'strustedFoldersentry for the project was written 24 s before the one session that kept the agent selected; every session that dropped the agent ran against the same folder while it was still untrusted. Re-tested after trusting the folder: the agent stayed selected across multiple sessions, its MCP tools attached, and it ranget_state/get_scenarios/get_instructions/initialize_scenarionormally. So in the App, this isn't a race at all — an untrusted workspace silently falls back to the default agent instead of surfacing a trust prompt or error for the selected plugin agent. Apologies for the earlier mischaracterization.Separately (same trusted session): once sandboxing was also enabled for the project,
initialize_scenario's write under.github/upgrades/scenarios/...failed with "Access … is denied," even though real filesystem ACLs allow the write and the sandbox policy panel shows the workspace as read/write. So the sandbox's read/write grant isn't reaching this MCP server's process. Likely intentional scoping rather than a bug, but worth documenting: a plugin MCP server that writes inside the workspace needs an explicit sandbox allowance, or sandboxing needs to be off, even though the UI says the workspace itself is writable.