[agent-issue]: make generated SafeOutputs MCP trusted and explicitly allowed by Copilot CLI

[krubenok]

Submission requirements

• I generated this issue with an agent that used .github/agents/ado-aw.agent.md.
• I reviewed the generated issue and confirm it is being filed directly in githubnext/ado-aw.

Problem summary

An ado-aw v0.43.0 workflow using Copilot CLI v1.0.69 cannot reliably invoke ado-aw's own generated safeoutputs MCP server without two manual .lock.yml edits:

1. Add isDefaultServer: true to the generated Copilot MCP configuration entry.
2. Add an explicit --allow-tool=safeoutputs argument even when ado-aw emits --allow-all-tools.

Without these edits, Copilot's third-party MCP policy treats the generated internal server as untrusted/not explicitly permitted. This is compiler-owned infrastructure, so workflow authors cannot represent either correction in source front matter; engine.args intentionally blocks compiler-controlled allow flags.

Reproduction details

Compile a workflow with ado-aw v0.43.0 using the Copilot engine, default wildcard tool access, and any safe output. The generated MCP conversion currently performs only these transformations:

.value.url |= sub("^http://[^/]+/"; "<gateway-prefix>/")
| .value.tools = ["*"]

The resulting safeoutputs entry lacks:

{
  "isDefaultServer": true
}

The generated Copilot invocation ends in --allow-all-tools and omits an explicit SafeOutputs permission. Although SafeOutputsExtension declares copilot_allow_tools: ["safeoutputs"], engine.rs discards all individual tool grants whenever wildcard bash selects --allow-all-tools.

In a production workflow, adding both of the following manual changes restores SafeOutputs access:

.value.isDefaultServer = true

--allow-all-tools --allow-tool=safeoutputs

A fresh v0.43.0 compile removes both patches. Current origin/main retains the same converter and mutually exclusive allow-list logic; the post-v0.43 MCPG dependency bump does not generate Copilot trust metadata.

Expected behavior: ado-aw's compiler-owned SafeOutputs MCP is trusted and invokable with the generated Copilot configuration without lock-file edits.

Observed behavior: two non-source-representable patches are required.

Proposed next step

Treat SafeOutputs as compiler-owned trusted infrastructure in the Copilot MCP conversion by emitting isDefaultServer: true. Also verify Copilot CLI's current permission semantics and emit an explicit --allow-tool=safeoutputs grant when required, even on the --allow-all-tools path. Add an integration/snapshot test for the final Copilot command and generated mcp-config.json shape using the currently pinned Copilot CLI contract.

[krubenok]

Validated the behavior across the affected ado-aw output and multiple recent Copilot CLI versions. This appears to be an ado-aw integration bug, not a recent Copilot runtime regression.

The relevant MCP trust behavior is consistent across the versions checked. ado-aw generates the SafeOutputs MCP as compiler-owned infrastructure, but the converted Copilot MCP configuration does not identify it as trusted/default. As a result, it can be classified as a third-party server and blocked before its tools are exposed. The production before/after evidence confirms that adding the trust marker resolves that failure.

One nuance on the permission change: --allow-all-tools should normally cover MCP tool execution, so an additional --allow-tool=safeoutputs is not universally required. However, emitting the explicit grant is still appropriate as a least-privilege declaration and makes SafeOutputs resilient in environments where broad allow-all behavior is restricted by policy.

The trust marker should be scoped specifically to compiler-owned SafeOutputs infrastructure. User-configured MCP servers should not automatically be marked trusted.

[jamesadevine]

This is now in - though I have worked a proposal to prevent this class of issue in the future.

[jamesadevine]

#1486