ACP mode: MCP OAuth token is never persisted after successful sign-in — every new session re-opens the browser #5192

Describe the bug

In ACP mode (copilot --acp), the OAuth token for a remote HTTP MCP server is never written to disk or the OS keychain after a successful sign-in. Each new ACP session (for example, each new thread in an ACP client) starts unauthenticated, gets a 401, and opens the browser authorization page again.

Evidence from a successful sign-in (macOS, Atlassian remote MCP https://mcp.atlassian.com/v2/mcp):

14:32:47.301Z [INFO] [rust:acp::mcp_oauth] opened the MCP OAuth authorization page {"server_name":"atlassian-cloud"}
14:32:47.302Z [WARNING] [rust:copilot_runtime::session::mcp::agent_host] HTTP 401 challenge (...) {"server":"atlassian-cloud"}
14:32:59.348Z [INFO] [rust:rmcp::service] Service initialized as client {...}

• The tools work for the rest of that session. No log line shows a token being stored.
• ~/.copilot/mcp-oauth-config/ does not exist. MCP OAuth tokens for HTTP servers not reliably reused across sessions — duplicate cache-key entries force repeated re-auth #4695 says this is where tokens are cached (<hash>.tokens.json). COPILOT_HOME is unset and HOME is the default.
• A scan of files modified in the two minutes after sign-in found only browser profile files. Nothing changed under ~/.copilot, ~/.config, ~/Library/Application Support (excluding the browser), or the project directory.
• The keychain has no MCP or OAuth item. Only the copilot-cli GitHub login entry exists.
• The next ACP session, started about 50 minutes later, got a 401 and opened the authorization page again:

15:22:30Z [WARNING] [rust:copilot_runtime::session::mcp::agent_host] HTTP 401 challenge (...) {"server":"atlassian-cloud"}
15:22:30Z [INFO] [rust:acp::mcp_oauth] opened the MCP OAuth authorization page {"server_name":"atlassian-cloud"}
15:23:48Z ... timed out after 60s

So the token appears to be held only in memory for the lifetime of the ACP process.

Affected version

1.0.98 (installed by an ACP client, macOS arm64)

Steps to reproduce the behavior

1. Configure a remote OAuth MCP server, e.g. in the project's .mcp.json:
   {"mcpServers":{"atlassian-cloud":{"type":"http","url":"https://mcp.atlassian.com/v2/mcp"}}}
2. Start copilot --acp from an ACP client and open a session. The browser opens; complete the sign-in. The MCP tools work.
3. Close the session or process, then start a new ACP session in the same project.
4. The browser authorization page opens again. ~/.copilot/mcp-oauth-config/ still does not exist.

Expected behavior

• After a successful sign-in, the token (and refresh token) is persisted, either in ~/.copilot/mcp-oauth-config/ or in secure storage per Secure credential storage for HTTP MCP OAuth tokens #2783.
• Later ACP sessions reuse it silently, as the 1.0.90 release notes describe ("reuses a still-valid cached token").
• Ideally, when no valid token exists, the browser opens only when an MCP tool is actually used, not at session start.

Additional context

• Related to Regression (1.0.88 → 1.0.89): MCP OAuth authorization page opens on every ACP session instead of the challenge being resolved silently #4994 (the auth page opens on every ACP session since 1.0.89). This issue covers the underlying cause: nothing is persisted, so there is never a cached token to reuse.
• Also related: MCP OAuth tokens for HTTP servers not reliably reused across sessions — duplicate cache-key entries force repeated re-auth #4695 (duplicate cache keys preventing reuse) and Secure credential storage for HTTP MCP OAuth tokens #2783 (secure credential storage).
• Older 1.0.8x logs show the server only marked as "needing auth", with no browser opened.