codex-responses-api-proxy rejects base64 API keys, blocking responses-api-endpoint (e.g. Bedrock bearer tokens)

Summary

codex-responses-api-proxy validates the API key against [A-Za-z0-9_-] and refuses anything else. That makes the responses-api-endpoint (bring-your-own-endpoint) path unusable with any provider whose credential is base64, because the key is the only way to get an Authorization: Bearer value to that endpoint.

Concrete case: AWS Bedrock's OpenAI-compatible /openai/v1/responses endpoint takes a bearer token that is base64 (~460 chars, = padding). The action never reaches the model:

Error: API key may only contain ASCII letters, numbers, '-' or '_'
responses-api-proxy did not write server info   -> exit 1

Why it can't be worked around

The action has exactly one credential input, and it goes straight into the proxy (action.yml, "Start Responses API proxy"):

env:
  PROXY_API_KEY: ${{ inputs['openai-api-key'] }}
  UPSTREAM_URL: ${{ inputs['responses-api-endpoint'] }}
run: |
  printenv PROXY_API_KEY | env -u PROXY_API_KEY "${args[@]}"

responses-api-endpoint only swaps the upstream URL, so there is no separate place to put the upstream Authorization value. Transforming the key to satisfy the charset is not an option either: the proxy forwards it verbatim, so stripping or re-encoding it just fails auth at the provider.

Worth noting the failure is also misreported. The proxy prints the real error, but the step is backgrounded and reports outcome=success; the job fails ~10s later on the generic responses-api-proxy did not write server info, and run_codex is skipped. Anyone hitting this sees a message about a missing file rather than a rejected key.

Possible fixes, in order of how little they'd change

1. Relax the proxy's key validation (or gate it on the default endpoint). The restriction looks aimed at OpenAI-issued keys; when the caller supplies their own upstream, the key format is the provider's business.
2. Let the upstream credential be passed separately, e.g. upstream-authorization / --upstream-header, so openai-api-key stays an OpenAI concern.
3. Failing either, surface the proxy's stderr on the failing step so the cause is visible.

Related: #107 asks for first-class Bedrock support. This is narrower — the transport already works, one validation blocks it — so fixing it would unblock Bedrock (and Azure/any gateway with a non-alphanumeric key) without a new provider abstraction.

Environment

openai/codex-action@v1, GitHub-hosted ubuntu-latest, responses-api-endpoint pointed at AWS Bedrock's OpenAI-compatible endpoint, sandbox: read-only, safety-strategy: drop-sudo.

Start with the "Start Responses API proxy" step in action.yml, then trace the command to the proxy's API-key validation and its server-info/error handling. Compare the proposed credential and validation approaches, and verify that a supported nonstandard key reaches the configured responses-api-endpoint while failures expose the proxy's actual cause.