Motivation
Link to the gh-aw PR: github/gh-aw#41801 — fix: prevent double-escape of custom MCP server env/header secrets in generated lock files
Since v0.81.2, custom MCP server env (and HTTP headers) secrets containing ${{ secrets.X }} expressions were double-escaped in generated .lock.yml files, causing the MCP gateway to fail with Configuration is not valid JSON / Bad escaped character in JSON. The fix was merged but no E2E regression test exists.
Proposed test
- Workflow file:
test-copilot-mcp-custom-env-secret.md
- Trigger:
workflow_dispatch
- Engine: copilot
- Safe output:
add-comment or noop (to confirm the MCP server started successfully)
- Variant: standard
Minimal test prompt sketch
Define a workflow with a custom MCP server that includes an env: block using a ${{ secrets.SOME_SECRET }} expression (or a non-secret placeholder). On trigger, the agent should call a tool from that custom MCP server and emit a comment or noop confirming success. A failure at MCP gateway startup (due to double-escaped JSON) would cause the workflow to fail, providing a regression signal.
New fixtures or secrets needed
A real secret value is needed in githubnext/gh-aw-test for the MCP server env, OR the test can use a placeholder non-secret env value if the gateway accepts that without authentication. This is the main open question: identify a publicly available MCP server (or use the existing shared/mcp/ definitions) whose startup can be verified with an env variable.
Notes
test-copilot-mcp-printEnv.md already tests MCP env variable visibility, but uses a built-in MCP server, not a custom server with env: secrets.- This test specifically targets the
renderSharedMCPConfig / writeJSONStringMapSectionRaw code path introduced in #41801.
- If a suitable public MCP server with env configuration is not available, the test could verify only the compiled lock file output (compile-time regression), though runtime verification is preferred.
Generated by 🔍 Suggest New E2E Tests · 57 AIC · ⌖ 7.31 AIC · ⊞ 5.9K · ◷
Motivation
Link to the gh-aw PR: github/gh-aw#41801 — fix: prevent double-escape of custom MCP server env/header secrets in generated lock files
Since v0.81.2, custom MCP server
env(and HTTPheaders) secrets containing${{ secrets.X }}expressions were double-escaped in generated.lock.ymlfiles, causing the MCP gateway to fail withConfiguration is not valid JSON/Bad escaped character in JSON. The fix was merged but no E2E regression test exists.Proposed test
test-copilot-mcp-custom-env-secret.mdworkflow_dispatchadd-commentornoop(to confirm the MCP server started successfully)Minimal test prompt sketch
Define a workflow with a custom MCP server that includes an
env:block using a${{ secrets.SOME_SECRET }}expression (or a non-secret placeholder). On trigger, the agent should call a tool from that custom MCP server and emit a comment or noop confirming success. A failure at MCP gateway startup (due to double-escaped JSON) would cause the workflow to fail, providing a regression signal.New fixtures or secrets needed
A real secret value is needed in
githubnext/gh-aw-testfor the MCP server env, OR the test can use a placeholder non-secret env value if the gateway accepts that without authentication. This is the main open question: identify a publicly available MCP server (or use the existingshared/mcp/definitions) whose startup can be verified with an env variable.Notes
test-copilot-mcp-printEnv.mdalready tests MCP env variable visibility, but uses a built-in MCP server, not a custom server withenv:secrets.renderSharedMCPConfig/writeJSONStringMapSectionRawcode path introduced in #41801.