Blocked as auth fails whenever -p or --agent used (enterprise login)

Describe the bug

copilot fails to load due to auth issues when using -p --agent:

copilot -p "hello"

...worked fine.

Then if you run this, with --agent, it breaks:

copilot -p "hello" --agent my-agent

! Third-party MCP servers are disabled by your organization's Copilot policy. Only built-in servers are available.

Error: Authentication failed (Request ID: 2915:A0B85:4D563A2:5BD65FE:6A915A71)

Your GitHub token may be invalid, expired, or lacking the required permissions.

To resolve this, try the following:
  • Start 'copilot' and run the '/login' command to re-authenticate
  • If using a Fine-Grained PAT, ensure it has the 'Copilot Requests' permission enabled
  • If using COPILOT_GITHUB_TOKEN, GH_TOKEN or GITHUB_TOKEN environment variable, verify the token is valid and not expired
  • Run 'gh auth status' to check your current authentication status

And further more, once you do the above, then:

copilot -p "hello"

...is permanently broken too now with the same error as above, despite working moments before. Strange.

It's enterprise, so we are logged in via ghe.com.

Running a regular "copilot" is fine.

Version: 1.0.81

Can you please fix this latest blocking login bug. There should be no differing auth code paths just because of a -p or --agent parameter.

I suspect you've hardcoded or chosen api.githubcopilot.com incorrectly again (if so, please add some effective guardrails to prevent this, this is a repeated root cause of various login issues).

Affected version

No response

Steps to reproduce the behavior

No response

Expected behavior

No response

Additional context

No response

Start by reproducing the failure with the copilot CLI using -p, --agent, and the /login command in a ghe.com enterprise environment; compare the behavior with an interactive copilot run and check gh auth status. Done means both -p and --agent use the correct enterprise authentication path without breaking subsequent commands.