omits OAuth indicator from authorize request, causing wrong token audience

Summary

When running:

codex mcp login example-mcp --scopes myscope,offline_access

Codex CLI opens an OAuth authorize URL that includes the requested scopes, but omits the protected resource indicator for the target MCP server.

Because resource is missing, the authorization server can mint a token for a default audience instead of the MCP server being logged into.

Environment

• Codex CLI: codex-cli 0.111.0
• OS: macOS
• Arch: arm64

Reproduction

1. Configure an MCP server whose protected resource is something like:

``text
https://resource.example.com/mcp
``

1. Run:

``bash
codex mcp login example-mcp --scopes myscope,offline_access
``

1. Observe the authorize URL printed by Codex CLI.

Actual behavior

Codex CLI prints an authorize URL shaped like:

https://auth.example.com/connect/authorize?response_type=code&client_id=...&state=...&code_challenge=...&code_challenge_method=S256&redirect_uri=http%3A%2F%2F127.0.0.1%3ANNNNN%2Fcallback&scope=myscope+offline_access

The URL is missing:

&resource=https%3A%2F%2Fresource.example.com%2Fmcp

Login then reports success, but the resulting token audience is for a different resource than the MCP server being logged into.

Expected behavior

Codex CLI should include the discovered MCP protected resource in the OAuth request, for example:

...&scope=myscope+offline_access&resource=https%3A%2F%2Fresource.example.com%2Fmcp

The token request should also be checked to ensure the same resource value is carried through consistently.

Impact

This makes codex mcp login appear successful while producing a token for the wrong audience/resource, which then breaks authentication against the intended MCP server.

Notes

This appears to be an MCP OAuth flow issue in Codex CLI rather than a DCR issue.

The target MCP server advertises its protected resource via OAuth protected resource metadata, and the CLI appears to be honoring scopes but not the discovered resource indicator.