Task tool does not recognize new agents added after conversation start (hot-reload gap)

[htekdev]

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

1. Start a Copilot CLI conversation in a repo with .github/agents/
2. Create a new agent file: .github/agents/my-new-agent.agent.md
3. Trigger reload (via extension calling session.agent.reload RPC, or manually)
4. Try to use task tool with agent_type: "my-new-agent" - fails validation
5. Run /clear and 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:

1. Lazy validation - Instead of validating against a static enum, query the current agent registry at invocation time
2. Tool rebuild - Re-create the task tool when agents change, similar to how refreshTools handles extension tool changes
3. Event subscription - Have the task tool subscribe to session.custom_agents_updated and update its internal list

Option 1 (lazy validation) is simplest and most resilient.

Additional Context

• session.agent.reload is defined in the schema with stability: experimental
• Node SDK 1.0.10 does not expose agent.reload() in typed client - must use raw connection.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

[htekdev]

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_session tool 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.md files added mid-conversation become available to the task tool 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.