github / github/copilot-cli

Sub-agents with full tool access return empty with no error; restricted-tool agent types work identically

Abierto
#4,293 2 comentarios 0 reacciones 0 asignados Ver en GitHub
area:agents area:tools
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

Abrir la 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

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.