Frequent re-authentication required

Thanks for reporting the problem.

Does this only occur with non-interactive mode, or do you see it with the interactive CLI as well? If it occurs in the CLI, please use the /feedback command the next time it happens. Upload your logs and post the thread ID below. This will allow us to dig into the cause in more detail.

When it fails, does it start working again if you just relaunch the CLI and resume where you left off? Or does it continue to fail with a 401 once it's in that mode?

Does it ask you to re-auth when you restart, or do you need to explicitly /logout and log back in?

BTW, it's unlikely that this is related in any way to your subscription plan type.

Mostly on the CLI.

Next time I will use the feedback command. I guess I would upload my logs
and post the thread ID below the feedback command.

When it fails, it prompts me to log in again, and I do so, and it continues
working. Then, it prompts me to log in again because it's looking for the
API key or something.

So, yeah, it's not me; I do have restarted it a couple of times already,
but I'm just sending you the feedback. Already did the logo thing, the
restart thing. There's no 401 though. It's just like it prompts itself to
log in because it's trying to look for the API key or something.

I'm not an expert on this. You are.

Thank you for the fast response though.

On Fri, Jan 23, 2026 at 5:18 PM Eric Traut @.***> wrote:

etraut-openai left a comment (openai/codex#9794) <https://github.com/openai/codex/issues/9794#issuecomment-3792804866> Thanks for reporting the problem. Does this only occur with non-interactive mode, or do you see it with the interactive CLI as well? If it occurs in the CLI, please use the /feedback command the next time it happens. Upload your logs and post the thread ID below. This will allow us to dig into the cause in more detail. When it fails, does it start working again if you just relaunch the CLI and resume where you left off? Or does it continue to fail with a 401 once it's in that mode? Does it ask you to re-auth when you restart, or do you need to explicitly /logout and log back in? BTW, it's unlikely that this is related in any way to your subscription plan type. — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/9794#issuecomment-3792804866>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BLJBYTELT35YZPZFKDD543L4IKM4PAVCNFSM6AAAAACSW5N4VKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOOJSHAYDIOBWGY> . You are receiving this because you authored the thread.Message ID: @.***>

--
Fernando L. González H.

The symptoms you're describing are very odd.

A few more follow-up questions:

1. Are you logging in with your ChatGPT subscription, or are you using an API key? Based on the fact that you mentioned your "pro" account, I presume you're using your ChatGPT subscription login, but I wanted to confirm.
2. Are you using an LLM proxy or any other intermediary, or are you directly accessing the OpenAI endpoints?
3. Do you have any other non-default configuration settings in your config.toml file that might be relevant to this issue?

I encountered this error message when using the API.

@gaoconggit, please use the /feedback command to upload your logs and session details, then post the thread ID here.

I'm in the CI environment.

I encountered this problem right after upgrading from 0.87.0 to 0.92.0.

@gaoconggit, I think it's unlikely that you're experiencing the same underlying issue as the one reported by the OP, but I can't tell for sure without additional details. The OP is reporting a situation where Codex works for a while but then starts to receive 401 errors. Is that what you're seeing, or are you seeing a 401 immediately? A 401 typically indicates that your API key is invalid or has been revoked for some reason. You could try creating a new API key.

--config features.remote_models=false

---
It solved my problem.

Additional reproduction data: REST fallback drops auth header after websocket failure

Environment: Codex CLI 0.117.0, Linux x64, ChatGPT Pro OAuth (auth_mode: chatgpt)

Root cause identified: When the websocket endpoint (wss://api.openai.com/v1/responses) returns 500 Internal Server Error and exhausts all retry attempts, Codex falls back to the REST endpoint (https://api.openai.com/v1/responses). However, the REST fallback request is sent without the Authorization header, resulting in 401 "Missing bearer or basic authentication in header."

Reproduction steps:

1. During a period when wss://api.openai.com/v1/responses is returning 500 (server-side issue)
2. Run: codex exec --dangerously-bypass-approvals-and-sandbox "Print hello"
3. Observe: 10 websocket reconnect attempts (all 500), then REST fallback with 401
4. Codex exits with code 0 despite doing no work

Log output:

ERROR codex_api::endpoint::responses_websocket: failed to connect to websocket: HTTP error: 500 Internal Server Error, url: wss://api.openai.com/v1/responses
ERROR: Reconnecting... 1/5
[...repeats through 5/5, twice...]
ERROR: unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses, cf-ray: 9e37a91b2f35ff03-PDX, request id: req_5dfeb2d8d8dc46fb8aa470b5382c3072

Key observations:

• The same auth credentials work fine when websocket is healthy
• codex login status correctly shows "Logged in using ChatGPT"
• OPENAI_API_KEY env var is also set but REST fallback doesnt use it either
• The issue affects both OAuth and API key auth modes in the REST fallback path
• Exit code is 0 (success) even though no work was performed — this is a separate issue

Impact: Any automated pipeline (CI, agent loops, scheduled tasks) silently fails when websocket has transient issues. The combination of (1) dropped auth header and (2) exit code 0 means failures go undetected.

Suggested fix: Ensure the REST/HTTP fallback path in codex_api::endpoint propagates the same Authorization header (Bearer token or API key) that the websocket path uses.

@joeykrug, your analysis wouldn't explain what the OP was seeing. Websocket support wasn't added to the source base until about a month after this bug was filed. If you're seeing an issue involving websockets, please open a new issue. Use /feedback to upload your logs and session details and include the thread ID in the bug report. Thanks!

It sounds like the OP's issue was resolved, so I'm going to close this issue.