Support OAuth token registration fails during automated provisioning

Description

When provisioning a new instance with OpenAI Codex CLI pre-installed via automated SSH-based tooling, the OAuth token registration does not work non-interactively. The token must be manually registered by SSHing into the instance and running the auth flow interactively, which breaks fully automated deployment pipelines.

Steps to Reproduce

1. Deploy a new cloud instance (e.g., AWS Lightsail, DigitalOcean) with Codex CLI installed
2. Attempt to register the OAuth token via SSH (non-interactive):

``bash
ssh user@instance "codex auth login --api-key $OPENAI_API_KEY"
``

1. The auth command either hangs waiting for interactive input, or silently fails to persist credentials

Expected Behavior

There should be a non-interactive way to register/provision OAuth tokens or API keys, e.g.:

codex auth login --api-key <KEY> --non-interactive
# or
codex auth set-token <KEY>
# or via environment variable
export OPENAI_API_KEY=<KEY>

Actual Behavior

OAuth registration requires an interactive terminal (TTY). In automated provisioning (SSH commands without TTY allocation), the token registration fails. The only workaround is to manually SSH into the instance and run the auth flow interactively.

Environment

• Codex CLI version: latest (via npm)
• OS: Ubuntu 22.04 (AWS Lightsail / DigitalOcean / BytePlus)
• Node.js: v22.x
• Provisioning context: automated SSH (non-interactive, no TTY)

Use Case

We run a deployment CLI (clawmacdo) that provisions cloud instances with Codex, Claude Code, and Gemini CLI pre-installed. All other tools support non-interactive token setup, but Codex requires manual intervention, preventing fully automated deployments.

Suggested Solution

Support one of:

1. A --non-interactive flag on the auth command
2. A set-token / set-api-key subcommand that writes credentials directly
3. Reading OPENAI_API_KEY from environment and persisting it on first run