feat: opt ChatGPT auth into agent identity

[adrian-openai]

Stack

This is PR 2 of the simplified HAI single-run-task stack:

• #19047 Agent Identity assertion and task-registration primitives, including the shared run-task helper used by existing Agent Identity JWT auth.
• #19049 Disabled-by-default ChatGPT auth opt-in that provisions/reuses persisted Agent Identity runtime auth and its single run task.
• #19051 Run-scoped provider auth that uses one backend-owned task id for first-party inference and compaction requests.

#19054 collapsed out of the active stack because the simplified design no longer needs a separate background/control-plane task helper.

Summary

This PR adds the disabled-by-default path for normal ChatGPT-login Codex sessions to obtain Agent Identity runtime auth through the Codex backend. Existing Agent Identity JWT startup mode remains a separate path and does not require the feature flag.

What changed:

• adds the experimental use_agent_identity feature flag and config schema entry
• adds an explicit AgentIdentityAuthPolicy so call sites choose JwtOnly or ChatGptAuth instead of passing a bare boolean
• stores standalone Agent Identity JWT credentials separately from backend-registered Agent Identity records
• persists the registered Agent Identity record, private key, and single run task id in auth.json so process restarts reuse the same identity
• derives the agent/task registration base URL from ChatGPT/Codex auth config while keeping JWT JWKS lookup separate
• provisions and caches ChatGPT-derived Agent Identity runtime auth when use_agent_identity is enabled
• reuses the shared run-task registration helper from PR1 rather than adding a second task-registration path

This PR intentionally does not switch model inference over to AgentAssertion auth. The provider-auth integration lands in the next PR.

Testing

• just test -p codex-login

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 92cf11ed3b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Exclude SessionState from forked rollout history

keep_forked_rollout_item retains RolloutItem::SessionState, so a fork copies parent task-state lines into the child rollout. On a later resume, restore_persisted_agent_task replays the latest session-state entry and can restore the parent task_id into the forked thread, defeating independent task identity for forks.

Useful? React with 👍 / 👎.

[efrazer-oai]

High level not sure we want to persist the task id in rollout state. Ik in initial reviews of the old stack i flagged this as problematic due to the deeper problem (having different tasks for same session id), but idt this is the solution we'd want long term.

Reasoning

It seems orthogonal/like a (potentially unstable) implementation detail that our deeper auth logic shouldn't care about, and we can't gate rollout item changes on feature flag. Rollout data really matters & we'd want to keep very good hygiene.

If we can, let's default to making task id ephemeral and shield it as much as possible from core session code.

Solution Musing

As a related note, it'd be so awesome if we could actually choose the task id name or establish some link between a session id and a task id. That way we get consistency backend-side rather than having to concern a lot of our app-server code with this stuff.

Suggestion

So in the AuthEnum stack, we have pretty much everything related to auth abstracted into the 'Auth' provider. Almost every call basically only has to say 'hey give me an auth provider and have that inject headers'.

So I think what we can do when enabling agent-identity feature is adding a different auth provider. What'd be amazing as an abstraction is if we could store some of this ephemeral stuff in-memory on the auth object (e.g. hashmap of session ids to task ids) and basically have the provider take our 'auth' and potentially a session id hint.