Summary
When the orchestrator dispatches custom agents via task, the subagent.started event's agentDisplayName field sometimes correctly reports the registered displayName (e.g., "Tenant Metrics", "Outlier Detector") and sometimes reports "General Purpose Agent". The behavior is non-deterministic across runs on identical code.
Repro
const session = await client.createSession({
customAgents: [
{ name: "tenant-metrics", displayName: "Tenant Metrics", prompt: "..." },
{ name: "outlier-detector", displayName: "Outlier Detector", prompt: "..." },
/* ... 3 more named custom agents ... */
],
});
session.on("subagent.started", (evt) => console.log(evt.data.agentDisplayName));
await session.sendAndWait({ prompt: "Dispatch all five custom agents to analyze..." });
Observed across multiple runs of the same code, same commit, same SDK/CLI:
- Run 1: prints
"Tenant Metrics", "Outlier Detector", etc. correctly
- Run 2: prints
"General Purpose Agent" for all 5 agents
Expected
agentDisplayName consistently matches customAgents[].displayName (or, when not set, falls back to customAgents[].name).
Actual
Non-deterministic. The intermittency is the larger concern — it suggests state leaking across runs or initialization-order sensitivity in the CLI's agent registration path.
Evidence (SDK source — limited)
nodejs/src/generated/session-events.ts: SubagentStartedData includes agentDisplayName: string. The SDK never populates this field — the event arrives over RPC from the CLI. The bug is in the CLI binary, which is not source-readable.
Consumer impact
- Dashboards and reports show
"General Purpose Agent" × N instead of distinguishable names.
- Per-agent metrics rollups (timings, token usage, cost) keyed by
agentDisplayName collapse to a single bucket.
Suggested fix
- Propagate the custom agent's
displayName (or the dispatching task call's name field) to subagent.started events consistently.
- Separately: root-cause the intermittency. Even if the display-name propagation lands, an intermittent CLI is a debugging hazard.
Related
Environment
- SDK: @github/copilot-sdk@0.3.0 (also observed on older versions)
- CLI: @github/copilot@1.0.45 (also observed on 1.0.14+)
- Node: 22 LTS
- OS: Windows 11
- Model: claude-sonnet-4-6
Summary
When the orchestrator dispatches custom agents via
task, thesubagent.startedevent'sagentDisplayNamefield sometimes correctly reports the registereddisplayName(e.g.,"Tenant Metrics","Outlier Detector") and sometimes reports"General Purpose Agent". The behavior is non-deterministic across runs on identical code.Repro
Observed across multiple runs of the same code, same commit, same SDK/CLI:
"Tenant Metrics","Outlier Detector", etc. correctly"General Purpose Agent"for all 5 agentsExpected
agentDisplayNameconsistently matchescustomAgents[].displayName(or, when not set, falls back tocustomAgents[].name).Actual
Non-deterministic. The intermittency is the larger concern — it suggests state leaking across runs or initialization-order sensitivity in the CLI's agent registration path.
Evidence (SDK source — limited)
nodejs/src/generated/session-events.ts:SubagentStartedDataincludesagentDisplayName: string. The SDK never populates this field — the event arrives over RPC from the CLI. The bug is in the CLI binary, which is not source-readable.Consumer impact
"General Purpose Agent" × Ninstead of distinguishable names.agentDisplayNamecollapse to a single bucket.Suggested fix
displayName(or the dispatchingtaskcall'snamefield) tosubagent.startedevents consistently.Related
agentIdmissing from SessionEvent in .NET, Go, and Python SDKs #1110 —agentIdmissing fromSessionEventin .NET, Go, and Python SDKs. Adjacent: anotherSessionEventfield that's not being populated reliably across SDKs/runtimes.Environment