What version of the Codex App are you using (From “About Codex” dialog)?
Codex App 26.707.72221 (build 5307), bundled codex-cli 0.144.2
What subscription do you have?
ChatGPT Pro
What platform is your computer?
Darwin 25.5.0 arm64 arm
What issue are you seeing?
A remote Streamable HTTP MCP server authenticates and works immediately after OAuth login, but stops working when the 15-minute access token expires.
The authorization server requires the RFC 8707 resource parameter in authorization and token requests, as required by the MCP 2025-11-25 authorization specification.
In Codex App 26.707.72221, after token expiry the MCP server becomes unavailable and a required MCP server can prevent creation of a new task:
Failed to initialize session: required MCP servers failed to initialize: supportpal: handshaking with MCP server failed: Send message error Transport [rmcp::transport::worker::WorkerTransport<rmcp::transport::streamable_http_client::StreamableHttpClientWorker<rmcp::transport::auth::AuthClient<codex_rmcp_client::http_client_adapter::StreamableHttpClientAdapter>>>] error: Auth error: OAuth authorization required, when send initialize request
Server-side audit showed that the access token had expired, while the rotating refresh token remained valid. With the bundled CLI 0.144.2, no successful refresh reached the token endpoint.
I repeated the test using codex-cli 0.144.3. That version attempted refresh, but omitted resource and failed with:
Token refresh not possible, re-authorization required: OAuth token refresh failed: Server returned error response: invalid_target: resource is required and must match this MCP server.
The project configuration already supplies the canonical resource:
[mcp_servers.supportpal]
url = "https://support.yourdomain.com/mcp"
oauth_resource = "https://support.yourdomain.com/mcp"
required = true
[mcp_servers.supportpal.oauth]
client_id = "codex-desktop-support-yourdomain"
The configured oauth_resource is present during login but is not included in the refresh-token request.
What steps can reproduce the bug?
- Configure a Streamable HTTP MCP server whose OAuth token endpoint requires
resource on every token request:
[mcp_servers.supportpal]
url = "https://support.yourdomain.com/mcp"
oauth_resource = "https://support.yourdomain.com/mcp"
required = true
[mcp_servers.supportpal.oauth]
client_id = "codex-desktop-support-yourdomain"
- Authenticate the MCP server through Codex App.
- Start a task and confirm that MCP initialization and a metadata-only tool call succeed.
- Wait until the access token expires. The test server uses a 15-minute access-token TTL and a 30-day rotating refresh-token TTL.
- Start another task or invoke the MCP server again.
- Observe that Codex App cannot restore the MCP connection. With codex-cli 0.144.3, the refresh request is sent without resource and the authorization server returns:
invalid_target: resource is required and must match this MCP server.
Investigation session ID:
019f5c1e-7426-7a42-bcbe-c1017fef84ef
The 0.144.3 command-line reproduction used codex exec --ephemeral. thread/start failed during required MCP initialization, before a persistent session ID was created.
Token-limit and context-window usage are not applicable; the failure happens during MCP initialization before the task starts.
What is the expected behavior?
Codex should include the configured canonical resource in every OAuth token request, including refresh-token requests:
resource=https://support.yourdomain.com/mcp
When the access token expires, Codex should use the still-valid refresh token, accept and persist the rotated refresh token, and continue using the MCP server without requiring another browser authorization.
A required MCP server should not prevent task creation when a valid refresh token can be refreshed successfully.
Additional information
The MCP specification requires clients to include resource in both authorization and token requests:
https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#resource-parameter-implementation
This exact omission was fixed upstream in the MCP Rust SDK on July 3, 2026:
modelcontextprotocol/rust-sdk#951
The PR states:
Refresh-token requests omitted the RFC 8707 resource parameter, which the spec requires on all token requests.
Codex 0.144.3 still pins rmcp 1.8.0, whose refresh path does not contain that fix. The Codex 0.144.3 release is documented as a version-only release with no merged changes since 0.144.2:
https://github.com/openai/codex/releases/tag/rust-v0.144.3
Codex previously added oauth_resource handling for MCP login flows in:
#12866
That change covered the authorization/login path, but not refresh-token requests.
Suggested fix: update the rmcp dependency to a revision containing modelcontextprotocol/rust-sdk#951, or cherry-pick the equivalent change so the refresh request includes the configured oauth_resource.
The MCP server should not be changed to accept refresh requests without resource, because doing so would weaken token audience binding. Setting required = false prevents the entire Codex task from failing, but it does not restore MCP access and is only an availability workaround.
What version of the Codex App are you using (From “About Codex” dialog)?
Codex App 26.707.72221 (build 5307), bundled codex-cli 0.144.2
What subscription do you have?
ChatGPT Pro
What platform is your computer?
Darwin 25.5.0 arm64 arm
What issue are you seeing?
A remote Streamable HTTP MCP server authenticates and works immediately after OAuth login, but stops working when the 15-minute access token expires.
The authorization server requires the RFC 8707
resourceparameter in authorization and token requests, as required by the MCP 2025-11-25 authorization specification.In Codex App 26.707.72221, after token expiry the MCP server becomes unavailable and a required MCP server can prevent creation of a new task:
Server-side audit showed that the access token had expired, while the rotating refresh token remained valid. With the bundled CLI 0.144.2, no successful refresh reached the token endpoint.
I repeated the test using codex-cli 0.144.3. That version attempted refresh, but omitted resource and failed with:
The project configuration already supplies the canonical resource:
The configured oauth_resource is present during login but is not included in the refresh-token request.
What steps can reproduce the bug?
resourceon every token request:Investigation session ID:
The 0.144.3 command-line reproduction used
codex exec --ephemeral.thread/startfailed during required MCP initialization, before a persistent session ID was created.Token-limit and context-window usage are not applicable; the failure happens during MCP initialization before the task starts.
What is the expected behavior?
Codex should include the configured canonical resource in every OAuth token request, including refresh-token requests:
When the access token expires, Codex should use the still-valid refresh token, accept and persist the rotated refresh token, and continue using the MCP server without requiring another browser authorization.
A required MCP server should not prevent task creation when a valid refresh token can be refreshed successfully.
Additional information
The MCP specification requires clients to include
resourcein both authorization and token requests:https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#resource-parameter-implementation
This exact omission was fixed upstream in the MCP Rust SDK on July 3, 2026:
modelcontextprotocol/rust-sdk#951
The PR states:
Codex 0.144.3 still pins
rmcp1.8.0, whose refresh path does not contain that fix. The Codex 0.144.3 release is documented as a version-only release with no merged changes since 0.144.2:https://github.com/openai/codex/releases/tag/rust-v0.144.3
Codex previously added
oauth_resourcehandling for MCP login flows in:#12866
That change covered the authorization/login path, but not refresh-token requests.
Suggested fix: update the
rmcpdependency to a revision containing modelcontextprotocol/rust-sdk#951, or cherry-pick the equivalent change so the refresh request includes the configuredoauth_resource.The MCP server should not be changed to accept refresh requests without
resource, because doing so would weaken token audience binding. Settingrequired = falseprevents the entire Codex task from failing, but it does not restore MCP access and is only an availability workaround.