What version of Codex CLI is running?

codex-cli 0.118.0

What subscription do you have?

Plus

Which model were you using?

N/A

What platform is your computer?

Darwin 25.3.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

Zed integrated terminal

What issue are you seeing?

When using codex --remote against a secure remote app-server endpoint over wss://, the CLI panics immediately with a rustls CryptoProvider error instead of connecting.

The same app-server works correctly over local ws://127.0.0.1:4222, and the same remote endpoint is reachable over wss:// through Tailscale Funnel.

Crash output:

Could not automatically determine the process-level CryptoProvider from Rustls crate features.
Call CryptoProvider::install_default() before this point to select a provider manually, or make sure exactly one of the 'aws-lc-rs' and 'ring' features is enabled.

This appears to be a CLI remote-client bug in the secure websocket path, not an app-server or tunnel issue.

What steps can reproduce the bug?

1. Create a websocket auth token file for app-server.
2. Start app-server locally:

   codex app-server \
     --listen ws://127.0.0.1:4222 \
     --ws-auth capability-token \
     --ws-token-file /Users/example/.codex/app-server/ws-token

3. Expose that local port through Tailscale Funnel:

   tailscale funnel --bg --yes http://127.0.0.1:4222

4. Confirm the public endpoint is live:

   tailscale funnel status

   Example hostname:

   https://example-device.example-tailnet.ts.net

5. Set the auth token env var:

   export CODEX_REMOTE_AUTH_TOKEN="$(cat /Users/example/.codex/app-server/ws-token)"

6. Run the local test, which works:

   codex --remote ws://127.0.0.1:4222 --remote-auth-token-env CODEX_REMOTE_AUTH_TOKEN

7. Run the secure remote test, which crashes:

   codex --remote wss://example-device.example-tailnet.ts.net:443 --remote-auth-token-env CODEX_REMOTE_AUTH_TOKEN

What is the expected behavior?

codex --remote wss://... should connect successfully to the remote app-server, just as codex --remote ws://127.0.0.1:4222 does locally.

It should not panic during secure websocket setup.

Additional information

I verified that the remote endpoint itself is healthy and that this is not a server-side auth/tunnel problem:

• GET /readyz and GET /healthz over the Funnel hostname both returned 200
• A manual websocket upgrade probe to the Funnel hostname returned 101 Switching Protocols
• The Authorization: Bearer <token> header was accepted by app-server
• Local ws://127.0.0.1:4222 remote mode works

I also locally patched the repo and confirmed the issue is in the secure remote client path.

Local fix that removes the panic:

• add codex-utils-rustls-provider as a dependency to codex-app-server-client
• call ensure_rustls_crypto_provider() before connect_async(request) in codex-rs/app-server-client/src/remote.rs

Minimal patch:

diff --git a/codex-rs/app-server-client/Cargo.toml b/codex-rs/app-server-client/Cargo.toml
@@
 codex-feedback = { workspace = true }
 codex-protocol = { workspace = true }
+codex-utils-rustls-provider = { workspace = true }

diff --git a/codex-rs/app-server-client/src/remote.rs b/codex-rs/app-server-client/src/remote.rs
@@
 use codex_app_server_protocol::ServerNotification;
 use codex_app_server_protocol::ServerRequest;
+use codex_utils_rustls_provider::ensure_rustls_crypto_provider;
@@
         if let Some(auth_token) = args.auth_token.as_deref() {
             ...
         }
+        ensure_rustls_crypto_provider();
         let stream = timeout(CONNECT_TIMEOUT, connect_async(request))

I ran:

just fmt
cargo test -p codex-app-server-client
cargo build -p codex-cli --bin codex

and the patched crate tests passed locally.