github / github/copilot-cli

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

Aperta
#4,293 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub
area:agents area:tools
Lingua principale
Shell
Stelle
11.2k
Fork
1.9k
Merge medio
14h 16m
PR unite (30g)
6

Descrizione

## 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.

Guida per i contributori

Apri la guida per i contributori

Direzione di ricerca

Inizia dal task tool e dalla gestione dell’agent-type dei sub-agents, riproducendo la matrice di prompt fornita con accesso completo e limitato agli strumenti. Verifica come vengono propagate e registrate le risposte vuote e gli errori; il lavoro è completato quando il parent riceve la risposta o un errore utilizzabile, invece di un risultato vuoto silenzioso.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Ambito
ai, cli, tooling
Tipo di issue
Bug
Difficoltà
4/5
Tempo stimato
3-5 giorni
Stato di attività
Tranquilla
Chiarezza
Abbastanza chiara
Idoneità per principianti
50/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.