Non-interactive mode: late-connecting MCP server injects empty user message; model echoes system-prompt tool lists instead of answering

[marcelsafin]

Describe the bug

Run copilot -p "..." with an MCP server that exposes 7 or more tools. The CLI appends an empty user message right after the real prompt. The model then answers the empty turn instead of the prompt. In several of my sessions it echoed fragments of its own system prompt (the deferred-tools listings), starting mid-word.

I bisected the trigger with a minimal stdio MCP server (script below): identical runs with the tool count as the only variable.

tools exposed	user.message events	result
2	1	correct answer
5	1	correct answer
6	1	correct answer
7	2 (second empty)	bug
8, 10, 17, 25	2 (second empty)	bug

The 6→7 boundary suggests the tool-deferral mechanism (large tool sets moved to on-demand loading) injects the empty turn. Slow server startup is not required; a server that responds instantly triggers it too.

Evidence from ~/.copilot/session-state/<id>/events.jsonl, two user.message events 130 ms apart, the second one empty:

16:41:22.133 user.message      len=24   :: 'Reply with exactly: PONG'
16:41:22.263 user.message      len=0    :: ''
16:41:34.591 assistant.message len=1624 :: '-quality-feedback MCP server. Tools prefixed with `model-quality-`:\n- report_model_quality_issue...'

The assistant reply starts mid-word (-quality-feedback MCP server...): it echoes the deferred-tools listing from the system prompt rather than answering. The garbage echo does not happen on every run; with a small 25-tool dummy the model sometimes still answered PONG despite the empty turn. The empty extra turn appears on 100% of runs at ≥7 tools. Any script or subagent built on copilot -p risks corrupted output.

Affected version

1.0.68 (macOS, Darwin arm64)

Steps to reproduce the behavior

1. Save this minimal MCP server as /tmp/slowmcp.py:

#!/usr/bin/env python3
import json, sys

TOOLS = [{"name": f"dummy_tool_{i}", "description": f"dummy tool number {i}",
          "inputSchema": {"type": "object", "properties": {"text": {"type": "string"}}}}
         for i in range(7)]  # 7 = minimum that triggers; 6 does not

for line in sys.stdin:
    try:
        req = json.loads(line)
    except json.JSONDecodeError:
        continue
    rid, method = req.get("id"), req.get("method", "")
    if method == "initialize":
        resp = {"jsonrpc": "2.0", "id": rid, "result": {
            "protocolVersion": "2025-11-25",
            "capabilities": {"tools": {}},
            "serverInfo": {"name": "slowdummy-mcp", "version": "2.0.0"}}}
    elif method == "tools/list":
        resp = {"jsonrpc": "2.0", "id": rid, "result": {"tools": TOOLS}}
    elif rid is not None:
        resp = {"jsonrpc": "2.0", "id": rid, "result": {}}
    else:
        continue
    sys.stdout.write(json.dumps(resp) + "\n")
    sys.stdout.flush()

2. Point ~/.copilot/mcp-config.json at it:

{"mcpServers": {"slowdummy": {"type": "stdio", "command": "python3", "args": ["/tmp/slowmcp.py"], "tools": ["*"]}}}

3. Run copilot -p 'Reply with exactly: PONG'
4. Inspect ~/.copilot/session-state/<session>/events.jsonl: two user.message events, the second with empty content. Change range(7) to range(6) and rerun: one user.message, correct answer.

Expected behavior

The model answers the prompt (PONG). The session log contains exactly one user.message event, regardless of how many tools the configured MCP servers expose.

Actual behavior

With ≥7 tools on one MCP server, the CLI appends a second, empty user.message 100-200 ms after the prompt. The model responds to the empty turn; on some runs it echoes system-prompt tool listings starting mid-word instead of answering.

Additional context

• Ruled out via the same bisection setup: slow startup (3 s delayed handshake: no bug), notifications/tools/list_changed after the prompt (no bug), instructions in the initialize result (no bug), full capability set including prompts/resources/completions/logging (no bug). Tool count is the single deciding variable.
• First seen with notebooklm-mcp (about 20 tools); reproduced with the dummy above to remove third-party code from the equation.
• Workaround: keep every MCP server at 6 or fewer exposed tools via the tools allowlist in mcp-config.json.
• I can share full redacted events.jsonl excerpts from the bisection runs if useful.

[marcelsafin]

Update: I bisected the trigger and rewrote the issue body. The original report blamed slow MCP-server startup; that was wrong. The deciding variable is the number of tools the server exposes: 6 or fewer is fine, 7 or more injects the empty user message (100% of runs, server responds instantly). The body now contains a self-contained ~30-line Python repro with no third-party dependencies, plus the bisection table and the ruled-out hypotheses (slow start, tools/list_changed, instructions, extra capabilities).