Repository navigation
Task tool does not recognize new agents added after conversation start (hot-reload gap) #3106
Description
Summary
When a new .agent.md file is added to .github/agents/ during an active conversation, the task tool's agent_type enum does not update - even after session.agent.reload successfully rescans the disk and the server's agent registry is refreshed. Users must start a new conversation (/clear) for the task tool to recognize newly added agents.
Expected Behavior
After session.agent.reload is triggered (via extension or other mechanism), the task tool should recognize newly loaded agents within the same conversation - no restart required.
Actual Behavior
The task tool captures its agent list once in a closure at creation time and never refreshes it. Even though session.agent.reload RPC exists, works, and the server emits session.custom_agents_updated event, the task tool's closure remains stale.
Reproduction Steps
- Start a Copilot CLI conversation in a repo with
.github/agents/ - Create a new agent file:
.github/agents/my-new-agent.agent.md - Trigger reload (via extension calling
session.agent.reloadRPC, or manually) - Try to use
tasktool withagent_type: "my-new-agent"- fails validation - Run
/clearand try again - now it works
Root Cause
taskTool.ts builds the allAgentNames array in a closure when the tool is first created. There is no mechanism to rebuild this closure when agents change. The refreshTools path only handles externalToolsVersion changes (extension tools), not agent list mutations.
Proposed Fix
When session.custom_agents_updated is emitted (after reload), the task tool's agent enum should be refreshed. Options:
- Lazy validation - Instead of validating against a static enum, query the current agent registry at invocation time
- Tool rebuild - Re-create the task tool when agents change, similar to how
refreshToolshandles extension tool changes - Event subscription - Have the task tool subscribe to
session.custom_agents_updatedand update its internal list
Option 1 (lazy validation) is simplest and most resilient.
Additional Context
session.agent.reloadis defined in the schema with stability: experimental- Node SDK 1.0.10 does not expose
agent.reload()in typed client - must use rawconnection.sendRequest - Extensions CAN trigger reload successfully; the gap is only in the task tool's stale closure
- This blocks agent hot-reload workflows where developers iterate without restarting conversations
Environment
- Copilot CLI (latest as of 2025-07)
- @github/copilot SDK 1.0.10
- Windows 11
Activity
htekdev commentedon May 5, 2026
I built a workaround extension that enables programmatic session restart, allowing newly created agents to become discoverable without manual intervention:
Repo: https://github.com/htekdev/copilot-self-restart
Blog post: https://htek.dev/articles/copilot-cli-self-restart-extension
It exposes a
restart_sessiontool that terminates the current CLI process and respawns with--resume, preserving conversation context. The new session loads a fresh agent registry on startup, so any.github/agents/*.agent.mdfiles added mid-conversation become available to thetasktool immediately.This is a stopgap until the runtime natively supports dynamic agent discovery (Option 1 — lazy validation — from the proposal above would eliminate the need entirely). Happy to discuss the approach if it helps inform a first-party solution.
patniko commentedon Oct 26, 2026
Thanks for the report. We've shipped fixes in this area since this was filed (most recently in Copilot CLI v1.0.90), and we believe this may now be resolved. Could you retest on the latest release (Copilot CLI v1.0.103) and let us know whether you still see it? If we don't hear back in a couple of weeks, we may close this issue — you can always reopen it.
Triaged as part of a Copilot SDK backlog review, with help from GitHub Copilot.