FLEET: fleet.start() ignores customAgents — always dispatches built-in agent types

[darthmolen]

Summary

When a session is created with customAgents defined, calling rpc.fleet.start() ignores the registered custom agents entirely. Sub-agents are dispatched as built-in types (explore, general-purpose, etc.), never as the custom agents registered in the session config.

Steps to Reproduce

const session = await client.createSession({
    onPermissionRequest: async () => ({ approved: true }),
    customAgents: [{
        name: 'my-researcher',
        displayName: 'My Researcher',
        description: 'A custom agent that only reads files.',
        prompt: 'You are a focused research agent. Only read files.',
        tools: ['view', 'grep'],
        infer: false,
    }],
});

// Confirm registered:
const agentList = await session.rpc.agent.list();
// → { agents: [{ name: 'my-researcher', ... }] }  ✓ registered

await session.rpc.fleet.start({ prompt: 'Research X in parallel' });

session.on('subagent.started', (data) => {
    console.log(data.agentName);
    // → 'explore'   ← always built-in, never 'my-researcher'
});

Observed Behaviour

Fleet dispatches explore built-ins regardless of customAgents config. The custom agent is visible in rpc.agent.list() immediately before the fleet call, confirming registration is not the issue.

Spike data (2026-03-17):

{
  "agentNamesObserved": ["explore", "explore"],
  "subagentCount": 2,
  "answer": "PARTIAL — dispatched built-in names, not custom names"
}

Expected Behaviour

One of:

1. fleet.start() uses custom agents when registered in the session
2. fleet.start() accepts agentNames: string[] to specify which agents to dispatch
3. Documentation clarifies fleet only uses built-in types (so callers know not to expect otherwise)

Impact

• Custom agent tool restrictions (customAgents[n].tools) cannot be applied to fleet workers
• Custom system prompts are ignored during fleet
• Fleet workers always get unrestricted built-in agent capabilities regardless of session config

Environment

• SDK: @github/copilot-sdk v0.1.32
• CLI: latest
• Node: v24.13.1

[brolnickij]

We are hitting the same issue from the Copilot CLI side (v1.0.11, macOS).

Our setup: Custom agents defined in .github/agents/*.agent.md (e.g. dev/code, dev/review, dev/commit). The CLI lists them correctly at startup under "Custom Agents" and they work fine when selected interactively via /agent.

The problem: When the main agent tries to invoke a custom agent programmatically via the task tool with agent_type: "dev/code", it fails with:

Unknown agent_type: dev/code. Valid types are: explore, task, general-purpose, code-review, configure-copilot, search/context7, search/github, search/web, dev/code, dev/commit, dev/design, dev/docs, dev/retro, dev/review

Note: dev/code is listed in the valid types in the error message itself, yet the dispatch still fails. This applies to all custom agent types — dev/commit, dev/review, search/web, search/context7, etc.

This effectively makes custom agents unusable for agentic workflows where the main agent needs to delegate tasks to specialized sub-agents programmatically. The whole point of defining agents with restricted tools and specialized prompts is lost if they can only be invoked manually.

Environment:

• Copilot CLI v1.0.11
• macOS (Darwin)
• GitLab remote (no GitHub remote — we also see "could not load remote agents, no GitHub remote found" but local .github/agents/ files load fine for interactive use)