[codex] Use background task auth for additional backend calls

[adrian-openai]

Summary

Splits the larger PR4.1 background task auth rollout by moving additional backend/control-plane call sites into this downstream PR.

This PR keeps callers on the same design as PR4.1: most code asks AuthManager for the default ChatGPT backend authorization header, and AuthManager decides bearer vs background AgentAssertion internally. Task-pinned inference auth remains separate because it needs the thread's registered task id.

Stack

• PR1: Add use_agent_identity feature flag #17385 - add features.use_agent_identity
• PR2: Register agent identities behind use_agent_identity #17386 - register agent identities when enabled
• PR3: Register agent tasks behind use_agent_identity #17387 - register agent tasks when enabled
• PR3.1: Persist and prewarm agent tasks per thread #17978 - persist and prewarm registered tasks per thread
• PR4: [codex] Use AgentAssertion downstream behind use_agent_identity #17980 - use task-scoped AgentAssertion for downstream calls
• PR4.1: [codex] Use background agent task auth for backend calls #18094 - introduce AuthManager-owned background/control-plane AgentAssertion auth
• PR4.2: this PR - use background task auth for additional backend/control-plane calls

What Changed

• pass full authorization header values through backend-client and cloud-tasks-client call paths where needed
• move ChatGPT client, cloud requirements, cloud tasks, thread-manager, and models-manager background auth usage into this downstream slice
• make app-server remote control enrollment/websocket auth ask AuthManager for the local backend authorization header instead of threading a background auth mode through transport options
• keep the same feature-gated bearer fallback behavior from PR4.1

Validation

• just fmt
• cargo check -p codex-core -p codex-login -p codex-analytics -p codex-app-server -p codex-cloud-requirements -p codex-cloud-tasks -p codex-models-manager -p codex-chatgpt -p codex-model-provider -p codex-mcp -p codex-core-skills
• cargo test -p codex-login agent_identity
• cargo test -p codex-model-provider bearer_auth_provider
• cargo test -p codex-core agent_assertion
• cargo test -p codex-app-server remote_control
• cargo test -p codex-cloud-requirements fetch_cloud_requirements
• cargo test -p codex-models-manager manager::tests
• cargo test -p codex-chatgpt
• cargo test -p codex-cloud-tasks
• just fix -p codex-core -p codex-login -p codex-analytics -p codex-app-server -p codex-cloud-requirements -p codex-cloud-tasks -p codex-models-manager -p codex-chatgpt -p codex-model-provider -p codex-mcp -p codex-core-skills
• just fix -p codex-app-server
• git diff --check

[shijie-oai]

I don't think we should be worried about if the remote control should be using anget identity or not? The app server on the remote device should have its own feature enabled?

[adrian-openai]

The added mode applies to the local app-server process opening the remote-control websocket to the ChatGPT/control-plane backend. It is not a setting sent across the websocket to tell the other end what to do.

The flow is:

• run_main_with_transport has the app-server Config.
• That config knows whether Feature::UseAgentIdentity is enabled.
• The remote-control transport needs to build the Authorization header for enrollment/websocket connection.
• The low-level websocket connector does not have Config, so the feature-derived BackgroundAgentTaskAuthMode gets threaded down.
• If enabled, it may use a background AgentAssertion authorization header.
• If disabled or unsupported, it falls back to bearer.
• So the remote side cannot “respect its own config” for this decision because this decision happens before the request is sent. The remote side can validate the auth it receives, but it does not choose whether this client process sends bearer vs AgentAssertion.

Let me know if that makes sense. I was wrong about this being part of slingshot!