Tamer + GitHub Copilot CLI: an honest field report

At tamer, our goal is to be agent-agnostic. Whether you use Claude Code, Aider, or Copilot, tamer should be able to encapsulate, secure, and orchestrate them.

Recently, we pushed GitHub Copilot CLI to its limits by attempting to use it as an automated "worker" within a pipeline supervised by a Master Agent. The result? Impressive power, but real technical frustration. Here is our honest field report.

The Concept: Copilot as a Specialized Worker

The idea was simple: the Master Agent detects a build error, generates a clear instruction, and sends it to a worker running gh copilot suggest. The worker retrieves the suggested command, executes it in its Landlock sandbox, and reports back to the Master.

On paper, it's the ideal workflow. In practice, we identified three major bugs that currently prevent 100% programmatic supervision.

Bug A: The "Silent Buffer" Syndrome

This is the most flagrant issue. In our integration via PTY (Pseudo-Terminal), the worker_message tool manages to inject the instruction text into Copilot CLI's standard input. However, in about 30% of cases, the tool "forgets" to send the final \n (Enter) character or it is not interpreted.

The result: Copilot's buffer fills up silently. The tamer tool returns success:true (because the message was successfully written to the stream), but Copilot waits indefinitely. To the Master Agent, the worker appears to be working, when it is actually just waiting for a keypress.

Bug B: The Phantom Approval

Tamer relies on the concept of Human-in-the-Loop (HITL). Any sensitive command must be approved. Normally, a worker emits an approval_request event via the MCP protocol, which you receive on your phone.

With Copilot CLI, this event is never emitted. The agent attempts to execute the command directly or via its own internal mechanism, bypassing tamer's MCP transport layer. Consequently, the worker_approve tool becomes unusable, and the pipeline stops because it cannot validate the action.

Bug C: Windows Line-Ending Hell

For our Windows users, the experience is even more complex. We observed that the \n line-ending characters are sometimes replaced by | (a vertical bar surrounded by spaces) during transit via worker_message.

This is not just an aesthetic problem: it completely destroys the Markdown formatting of Copilot's explanations and breaks the "self-critique gate" (our automatic verification mechanism). The agent can no longer re-read its own code because it is polluted by these transport artifacts.

Conclusion: Not Quite Ready for Full Autonomy

GitHub Copilot CLI remains a formidable tool for interactive use by a human. However, for automated multi-agent orchestration, it still lacks "programmatic transparency."

Today, we cannot recommend Copilot CLI as a primary worker for complex pipelines without constant human supervision behind the terminal.

Next Steps for Tamer: We have opened three Work Items (WIs) to attempt to work around these limitations on the tamer side, notably by hardening our PTY management to force the interpretation of key sequences.

Agentic engineering is a science of details. Sometimes, the future of AI is just one "Enter" key away.

Related Work Items:

• [WI-PTY-FORCE-NEWLINE] Hardened PTY newline injection
• [WI-MCP-COPILOT-BRIDGE] Shim for Copilot approval events
• [WI-WIN-LINE-ENDINGS] Cross-platform line-ending normalization