Sub-agents with full tool access return empty with no error; restricted-tool agent types work identically
- Lenguaje dominante
- Shell
- Estrellas
- 11.2k
- Forks
- 1.9k
- Merge medio
- 14 h 16 min
- PR fusionados (30 d)
- 6
Descripción
## Describe the bug
Sub-agents launched via the `task` tool return **no response at all** — no error, no partial output, no log entry — when the agent type has access to the full tool set. The same model, same prompt, and same session succeed when launched with a restricted-tool agent type.
The tool call returns `Agent completed but produced no response.` and the parent agent has no way to distinguish this from a legitimately empty answer.
## Affected version
CLI `1.0.73`, GitHub Copilot desktop app, Windows 11 x64.
## Steps to reproduce the behavior
With 12 MCP servers configured (mix of stdio and http), run the same trivial prompt through different agent types:
```
task(agent_type: "explore", model: "gpt-5.6-sol", prompt: "Reply with exactly: ALIVE-SOL-EXPLORE. Do not use any tools. Nothing else.")
task(agent_type: "general-purpose", model: "gpt-5.6-sol", prompt: "Reply with exactly: ALIVE. Nothing else.")
task(agent_type: "rubber-duck", model: "gpt-5.6-sol", prompt: "Reply with exactly: ALIVE-DUCK. Do not use any tools. Nothing else.")
task(agent_type: "task", model: "gpt-5.6-sol", prompt: "Reply with exactly: ALIVE-TASK. Do not use any tools. Nothing else.")
```
Results:
| agent_type | tool access | result |
|---|---|---|
| `explore` | restricted (grep/glob/view/bash) | ✅ returns `ALIVE-SOL-EXPLORE` |
| `general-purpose` | all tools + MCP | ❌ empty |
| `rubber-duck` | all tools + MCP | ❌ empty |
| `task` | all CLI tools | ❌ empty |
This is **not** model-specific. The same matrix fails identically on `gpt-5.6-sol`, `gpt-5.6-terra`, and `claude-opus-4.8`, in both `sync` and `background` mode. It reproduces with a prompt that explicitly forbids tool use, so it is not caused by the sub-agent attempting a tool call.
## Expected behavior
Either the sub-agent returns its response, or the failure surfaces as an error the parent agent can act on. A silent empty return is the worst outcome: the parent cannot tell "the agent had nothing to say" from "the agent never ran".
## Additional context
**Nothing is logged.** The session CLI log contains zero `[ERROR]` or `[WARN]` entries during the sub-agent window. The only errors in the whole session log are unrelated MCP startup problems from ~60s earlier:
```
[ERROR] MCP server "workiq": also defined by plugin "workiq"; using the version from plugin "msx-mcp".
[ERROR] Failed to start MCP client for msx-mcp: failed to initialize MCP client: connection closed: initialize response
[ERROR] Failed to start MCP client for azure: failed to initialize MCP client: connection closed: initialize response
[ERROR] [rust:rmcp::transport::worker] worker quit with fatal: Transport channel closed, when Client(OAuthChallenge ...)
```
Session config: `contextTier: long_context`, `model: claude-opus-5`, `effortLevel: high`. 12 MCP servers configured (`powerbi-remote`, `pekg`, `WebIQ`, `workiq`, `aspire`, `context7`, `Eng-Hub`, `bluebird`, `microsoftdocs`, `foundry-mcp-remote`, `azure`, `msx-mcp`).
**Suspected cause, not proven:** the correlation is exactly with how much tool schema the agent type carries into context. That matches #3542, which measured ~573K tokens of enterprise MCP tool schema against a ~136K runtime cap and reported `contextTier: long_context` being ignored. I have verified the correlation with agent type and ruled out the model; I have **not** instrumented the actual token budget, so the causal link to schema size is inference rather than measurement.
If that is the mechanism, the fix in #3542 (honor `contextTier`, or lazy-load tool schemas) would likely resolve this too — but the silent-empty-return behaviour is worth fixing independently, since it turns a budget problem into an invisible one.
**Practical impact:** any workflow that delegates to `general-purpose` or a specialist agent silently produces nothing. In my case an entire adversarial code review returned empty four times across three models before I isolated the agent type as the variable. The workaround is to route work through `explore`, which defeats the purpose of the specialist types.
**Possibly related:** #3542 (MCP schema exceeds token limit), #2630 (custom agent `mcp-servers` not connected in sub-agent contexts), #3293 (extension tools not propagated to sub-agents).
### Separate observation
The same `~/.copilot/logs` directory contains single session logs of **6.25 GB** and **5.17 GB**. Whatever is being written at that volume may be worth a look independently of this bug.
Guía de contribución
Línea de trabajo
Empieza por el task tool y el manejo del agent-type de los sub-agents, reproduciendo la matriz de prompts proporcionada con acceso completo y restringido a las herramientas. Comprueba cómo se propagan y registran las respuestas vacías y los fallos; la tarea está terminada cuando el padre recibe la respuesta o un error accionable, en lugar de un resultado vacío silencioso.
Escrito por el modelo de indexación a partir del texto del issue.
Evaluación
- Área
- ai, cli, tooling
- Tipo de issue
- Error
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Estado de actividad
- Tranquilo
- Claridad
- Bastante claro
- Aptitud para principiantes
- 50/100