Describe the bug
GitHub Copilot CLI 1.0.9 on Windows appears to have a regression with third-party remote MCP servers in prompt mode (-p) and new non-interactive sessions.
What I expected:
A configured remote MCP server should be available in copilot -p, same as in interactive mode, per the Copilot CLI docs.
What actually happens:
web_search works in copilot -p, so networking is available.
mixpanel is configured in ~/.copilot/mcp-config.json.
- In interactive mode, Mixpanel can authenticate and connect successfully.
- But in
copilot -p and fresh copilot -i sessions, Mixpanel repeatedly fails with:
invalid_token / Authentication required
- The model then says Mixpanel MCP is not available in the session.
- In some runs, there are also
EPIPE: broken pipe, write errors.
Why this looks like a CLI regression:
- The same workflow reportedly worked on CLI 1.0.7.
- I cannot find any docs saying
-p should exclude MCP tools.
- Official docs describe MCP servers as available after configuration, and
-p as programmatic prompt execution.
Environment:
- OS: Windows
- Copilot CLI: 1.0.9
- MCP server: remote HTTP MCP (
https://mcp.mixpanel.com/mcp)
- Third-party MCP affected: Mixpanel
- Built-in/other networked tools still work:
web_search, microsoft-learn, github-mcp-server
Relevant symptoms from logs:
Server mixpanel requires authentication, initiating OAuth flow
Failed to start MCP client for remote server mixpanel: ... {"error":"invalid_token","error_description":"Authentication required"}
- In other sessions:
Successfully authenticated with mixpanel and Started MCP client for remote server mixpanel with OAuth
- Yet
copilot -p still says Mixpanel MCP is unavailable
- Some
-p runs also show EPIPE: broken pipe, write
This suggests a bug in MCP OAuth reuse/session handling or tool exposure for third-party remote MCP servers in non-interactive mode.
Affected version
No response
Steps to reproduce the behavior
No response
Expected behavior
No response
Additional context
No response
Describe the bug
GitHub Copilot CLI 1.0.9 on Windows appears to have a regression with third-party remote MCP servers in prompt mode (
-p) and new non-interactive sessions.What I expected:
A configured remote MCP server should be available in
copilot -p, same as in interactive mode, per the Copilot CLI docs.What actually happens:
web_searchworks incopilot -p, so networking is available.mixpanelis configured in~/.copilot/mcp-config.json.copilot -pand freshcopilot -isessions, Mixpanel repeatedly fails with:invalid_token/Authentication requiredEPIPE: broken pipe, writeerrors.Why this looks like a CLI regression:
-pshould exclude MCP tools.-pas programmatic prompt execution.Environment:
https://mcp.mixpanel.com/mcp)web_search,microsoft-learn,github-mcp-serverRelevant symptoms from logs:
Server mixpanel requires authentication, initiating OAuth flowFailed to start MCP client for remote server mixpanel: ... {"error":"invalid_token","error_description":"Authentication required"}Successfully authenticated with mixpanelandStarted MCP client for remote server mixpanel with OAuthcopilot -pstill says Mixpanel MCP is unavailable-pruns also showEPIPE: broken pipe, writeThis suggests a bug in MCP OAuth reuse/session handling or tool exposure for third-party remote MCP servers in non-interactive mode.
Affected version
No response
Steps to reproduce the behavior
No response
Expected behavior
No response
Additional context
No response