[codex] Auto provision AIProxy key

[Che-Zhu]

Summary

• Add automatic AIProxy token provisioning from Sealos kubeconfig.
• Persist a user-scoped aiproxy key idempotently without overwriting existing configuration.
• Gate task creation entry points on shared client-side provisioning and use the /v1 AIProxy model base URL.

Validation

• pnpm format:check
• pnpm type-check
• pnpm lint (0 errors, existing warnings remain)
• pnpm exec tsx scripts/verify-aiproxy-provisioning.ts

Notes

• expired_at is ignored because the live token lookup response may omit it.
• The API returns diagnostic enums for provisioning failures without logging token or kubeconfig values.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6be71a0c71

ℹ️ 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]

Skip mandatory AIProxy provisioning before task creation

This new early-return blocks task creation whenever ensureAiProxyProvisioned() fails, even though task execution can still succeed via the existing AI Gateway fallback path (resolveCodexGatewayFromApiKeys uses AI_GATEWAY_API_KEY when no AIProxy key is present). In environments where Sealos session/kubeconfig is unavailable (or temporarily fails), users now get a hard client-side stop instead of creating a valid task, so provisioning should be conditional rather than mandatory.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Retry token creation when lookup returns masked token

The 200 lookup path returns immediately, but validation rejects masked keys (masked_key), and the included token-management API reference documents masked keys for GET /tokens/{name} responses. That means if the upstream token already exists but the local DB row is missing, provisioning deterministically fails with unusable_token and never reaches the idempotent create endpoint that can return a usable key, leaving users unable to reprovision.

Useful? React with 👍 / 👎.