Short answer: if you searched codex reset because Codex is misbehaving, the fix is almost never a single reset. Codex has four separate resets, they live in four different places, and they are not interchangeable.
| What you actually want | What to do | What it clears | What it leaves alone |
|---|---|---|---|
| Free up context so the model stops forgetting | /compact, or /new / /clear | the conversation (summarised or dropped) | files on disk, config.toml, your login |
| Stop Codex calling an endpoint that no longer exists | delete the stale model_provider block from ~/.codex/config.toml | the custom provider route | your ChatGPT login, your history |
| Get logged in again | codex logout then codex login | cached credentials in ~/.codex/auth.json | config.toml |
| Stop the stream dying mid-answer | fix the transport: base_url, TLS trust, or the local proxy port | nothing; it repairs the link | everything above |
Pick the wrong row and one of two things happens. You wipe work you could have recovered, or you "reset" something that was never broken, and the same error comes straight back on the next message.
Reset #1 - context. The one everybody gets half right
Ctrl+L does not reset anything. It scrolls the terminal view. The conversation is still fully in the model's context, so the model still remembers everything, still carries every failed attempt, and still bills you for all of it. If your symptom is "it forgot what I told it ten minutes ago", the terminal is not the thing to clean.
There are three real levels, and they differ only in what they keep:
/compact- the conversation is summarised and the original transcript is replaced by that summary. Use it when the task is not finished and you do not want to lose the thread. Run/statusafterwards and check that the token number actually dropped; that is the only proof it worked./new- a fresh thread in the same process. The old history stops being sent to the model. Files you already created are untouched./clear-/newplus a cleared terminal. Same context effect, tidier screen.
One detail that only shows up after you have been burned: if /compact leaves you still near the ceiling, the conversation was simply too long for a summary to save you. /new is the answer, not a second /compact. The useful habit is to compress before the error, not after, because then you get to choose what survives.
Reset #2 - config. Deleting the model line is not enough
The single most misleading error in this family:
stream disconnected before completion: error sending request for url (http://127.0.0.1:57321/v1/responses)It reads like a network fault. It is usually a stale provider block. That URL is the tell: Codex is not talking to OpenAI at all. It is talking to something on 127.0.0.1:57321, and nothing is listening there.
The diagnostic that settles it in one command:
netstat -ano | findstr 57321Empty output means nothing is listening. Then check the config, because this is where the real problem lives:
model_provider = "CodexPlusPlus"
model = "deepseek-v4-flash"
[model_providers.CodexPlusPlus]
name = "CodexPlusPlus"
wire_api = "responses"
requires_openai_auth = true
base_url = "http://127.0.0.1:57321/v1"
experimental_bearer_token = "sk-xxx"And here is the trap. Changing the model line alone does not fix it. If model_provider = "CodexPlusPlus" is still in the file, Codex keeps routing through the dead provider and keeps failing. You have to delete the model_provider line *and* the whole [model_providers...] block. A minimal working config is three lines:
model = "gpt-5.5"
forced_login_method = "chatgpt"
disable_response_storage = trueThen re-establish the login:
codex logout
codex login
codex login statusLogged in using ChatGPT is the confirmation. Nothing else counts.
Two more things this scenario teaches. First, if you *do* want to keep a local proxy, start it and re-run netstat: you should see LISTENING on that port. Then check which API shape it speaks. Codex here is calling /v1/responses, while plenty of local model proxies only implement /v1/chat/completions. A proxy that is running but speaks the wrong API looks exactly like a proxy that is not running at all.
Second, the login step can fail on its own:
Token exchange failed: error sending request for url (https://auth.openai.com/oauth/token)
Error code
token_exchange_failedThat is a different failure: the transport to the auth endpoint, not the provider config. Test it directly:
curl -I https://auth.openai.com/oauth/token
curl -I https://api.openai.com
curl -I https://chatgpt.comIf those fail, change the route you are going out through. Config fixes will not help.
Reset #3 - auth. Where the reset is invisible
The OAuth callback is the part nobody tells you about. Codex's sign-in flow opens a browser, and the browser is redirected back to a fixed local address: localhost:1455. A small local listener receives the token there.
If something else on your machine already owns port 1455, your editor's port forwarding quietly remaps the remote 1455 to a free local port such as 1456. The browser still goes to localhost:1455. The listener is on localhost:1456. The token is delivered to nobody, and the symptom is an endless spinner or a bare failure page.
The fix is to take the port back, not to reinstall anything:
sudo lsof -i :1455
kill -9 <PID>Then in the editor's Ports panel, delete the old mapping and re-add 1455 explicitly, so the forwarded address reads exactly localhost:1455.
Rule out the network first so you are not chasing a ghost. If this returns HTTP 405 or 401, the machine can reach the auth endpoint fine and the problem is local:
curl -I https://auth.openai.com/oauth/tokenIf you are working over SSH or inside a container, do not attempt the browser flow at all. Authenticate on a machine with a browser, then copy the credential file to the same relative path on the target:
~/.codex/auth.jsonAnd treat that file as a password. It is a bearer credential. It does not belong in a repository, an issue, or a screenshot.
Reset #4 - transport. When everything above is correct and it still dies
Three causes account for most of it, and all three look identical from the error message.
A missing or duplicated slash in base_url. This is the one that eats entire days:
base_url = "https://your-relay.example//v1"One extra character. Requests go to a path that does not exist, the response body never parses, and you get stream disconnected before completion: stream closed before response. Fix the URL to a single slash and restart the client. If you added the double slash because someone's example showed it that way, you are not the first, and that is exactly how the mistake spreads.
A stale local trust store. On Windows the CLI and the browser do not verify certificates through the same path. The browser can show a perfectly normal chain while the CLI refuses:
curl: (60) schannel: SEC_E_UNTRUSTED_ROOT (0x80090325)The fix is to refresh the machine's root certificates rather than to touch Codex:
certutil -generateSSTFromWU roots.sst
certutil -addstore -f Root roots.sstTwo useful checks around it. If curl -I https://chatgpt.com starts returning a real HTTP response, even a 403 with a Cloudflare challenge, the TLS handshake is working again and you have moved past the certificate problem. And if your error text contains any of SEC_E_UNTRUSTED_ROOT, schannel, certificate, SSL, TLS, or unable to get local issuer certificate, treat it as a trust-chain problem before you suspect plan limits or quotas. The reverse is also true: an active subscription does not protect you from this, which is why "I pay for Plus, so it must be permissions" is the wrong first move.
A client that ignores your system proxy. Desktop and CLI clients frequently do not pick up system-wide proxy settings the way a browser does, so requests partly go through and partly do not, which is exactly the shape of Reconnecting 1/5 followed by a dead stream. The targeted fix is to tell Codex directly, in its own config directory:
C:\Users\<you>\.codex\.envHTTP_PROXY="http://127.0.0.1:<your-local-proxy-port>"
HTTPS_PROXY="http://127.0.0.1:<your-local-proxy-port>"
NO_PROXY="localhost,127.0.0.1,::1"NO_PROXY matters more than it looks. Without it, requests to your own local services get sent through the proxy too.
Two traps here. Windows hides known file extensions, so the file you think is .env is very often .env.txt, and Codex will not read it. And if the local proxy is not actually running, this change makes things *worse*, because you have now pointed Codex at a port with nothing behind it. Verify before and after:
Test-NetConnection -ComputerName 127.0.0.1 -Port <your-local-proxy-port>TcpTestSucceeded : True is the check. This is also why the app-level .env is worth trying before a system-wide TUN mode: it is narrower, it is easier to undo by deleting one file, and it tells you something either way.
The order to try them in
- Read the URL in the error. If it is
127.0.0.1or a relay, it is a config problem, not a Codex problem. - Confirm the process is running and the port is listening. Then confirm the port speaks
/v1/responses. - Check
base_urlcharacter by character. One slash. - If the error mentions TLS, certificates, or
schannel, refresh the trust store. - If sign-in spins, check the local port your editor forwarded and what the callback URL expects.
- If the connection drops only on long responses, give the client an explicit proxy and check
NO_PROXY. - Only then start deleting credentials and clearing context. Those are the last two resets, not the first two.
Compare the four resets
The table below is what the page's download entry serves as a file, and the same content prints cleanly on its own.
| Context reset | Config reset | Auth reset | Transport reset | |
|---|---|---|---|---|
| Trigger symptom | model forgets, context ceiling reached | error URL points at 127.0.0.1 or a relay | sign-in spins or fails | stream dies mid-answer |
| Command or setting | /compact, /new, /clear | edit ~/.codex/config.toml | codex logout then codex login | base_url, root certificates, .env |
| What it clears | conversation history | the stale provider route | auth.json credentials | nothing |
| What it keeps | files, config, login | login, history | config.toml | all of the above |
| Verify with | /status token count | netstat -ano | findstr <port> | codex login status | curl -I, Test-NetConnection |
| Reversible | yes | yes, restore the block | yes, log back in | yes, delete .env |
| Cost of picking wrong | lose recoverable work | error persists unchanged | unnecessary re-login | nothing, but wastes time |
Download this comparison
Header plus four rows.
Official release records, by date
Every row below was read off an OpenAI or openai/codex page, and every URL in the source column resolves to that exact entry. Nothing here is second-hand.
A note on how the desktop build numbers relate to the dates, because the two do not match and that is not an error. The build number encodes the build date, and the changelog entry is published two to three days later. 26.609 was built on 06-09 and the entry is dated 06-11. 26.707 was built on 07-07, entry 07-09. 26.727 was built on 07-27, entry 07-30. 26.908 was built on 09-08, entry 09-11. The lag is consistent across all four, which is itself the check.
One of these rows is worth reading in full rather than just listing. The 2026-06-11 entry is where rate-limit reset banking first appears for Plus and Pro users, described as one free reset at launch plus referral invitations for earning more during the promotion. That is the first-party statement of what a banked reset actually is, and it is the reason "reset" means two completely different things depending on whether you are talking about your conversation or your quota.
Where this leaves you
Four resets, four places to look, one keyword. The reason codex reset is such a frustrating search term is that the answer people actually need is usually not a reset at all. It is a one-character fix in a config file, a port number, or a certificate store. Start by reading the URL in the error message. It tells you which of the four you are in.