Codex 5.3 model not doing any file edits within CLI

Massive problem right now, makes 5.3 unusable for me.

Pic related is the modal interaction

<img width="1076" height="802" alt="Image" src="https://github.com/user-attachments/assets/6a2776e9-0822-4177-b511-e28c63b8ea2b" />

This is happening to me too, as are several people on Reddit, so glad to know it's not just me.

If you see this happen, please use the /feedback slash command to upload your logs and session details, then post the thread ID here. We'll need this additional information to investigate this issue.

Based on the details so far, this sounds like it might be model behavior that's baked in to 5.3, but the vast majority of users are not seeing this, so there's a mystery to be solved here.

I'm having the same issue. Totally unusable as an agent.
It should DO things and not chat with me!
Switched back to 5.2-codex.

If you see this happen, please use the /feedback slash command to upload your logs and session details, then post the thread ID here. We'll need this additional information to investigate this issue. Based on the details so far, this sounds like it might be model behavior that's baked in to 5.3, but the vast majority of users are not seeing this, so there's a mystery to be solved here.

Here is an chat ID: 019c4cea-5853-7d81-a83a-167e5fe8ebac

@etraut-openai

019c4f2f-f9fb-79d3-ae50-12569bdf1c3a

Spawned a fresh context in my project, hit this immediately on the first work item.

If you see this happen, please use the /feedback slash command to upload your logs and session details, then post the thread ID here. We'll need this additional information to investigate this issue. Based on the details so far, this sounds like it might be model behavior that's baked in to 5.3, but the vast majority of users are not seeing this, so there's a mystery to be solved here.

Any explanation for this, or tips to deal with it?

happened again.
chat id: 019c537c-e64f-78e1-9257-da247973a311

Thanks for the bug reports. I've looked at the sessions that have been uploaded (thanks!), and this does appear to be model behavior, not something that's under the control of the Codex harness. If you see additional instances of this, you're welcome to use the /feedback command to upload the session details. The team responsible for training our models can use that information to improve future models. No need to file more bug reports in github on this issue.

We may have a fix for this. Try using the /model slash command. Select "gpt-5.3-codex", then select a reasoning level (like "medium"). We're working on a theory that without explicitly selecting the reasoning level, the CLI defaulted to a "none" reasoning level, and that could explain the behaviors you're seeing here. Give that a try and let us know if the behavior improves.

Negative results, unfortunately:

RUN 1 (existing context): 019c4d15-d8a1-7630-b841-93a11b64ba3f

I explicitly set it to xhigh (in fact I always do this religiously when switching and have xhigh default in my config, which leads me to unfortunately doubt the hypothesis at play here from the start): what I observe is, no reading and no writing, though it confabulates having both read and written files which is even worse than just going limp imho. (picture attached -- I confirmed the mtime on the file predates the chat, so this was a straight up hallucination. This is not the first time I've seen this.)

RUN 2 (fresh context): 019c5455-db1d-71b0-b2d4-143d4b6f9db5

It complies at first, but when I repeatedly give it "read and write" type tasks (scan the codebase for X, write a report in Y) it reverts to "going limp": simply saying "yes I'll do that" but not actually doing it.

<img width="975" height="623" alt="Image" src="https://github.com/user-attachments/assets/b36dbdd6-58f9-4af7-893e-9072920b0b10" />

@qdbp, I looked at your logs and can confirm that the reasoning level sent to the model is null, which explains the behavior you're seeing. Now we need to determine why it's null. Do you have any other non-default overrides in your config file? For example, do you set model_supports_reasoning_summaries to false?

good catch, hopefully, I do have it set to false. I was under the impression this only affected third party models

I think you nailed it, I see an immediate behavior change here toward what I expect (internal plan generation, etc.) that I didn't see before.

I was under the impression this only affected third party models

Our current documentation is somewhat misleading. I'll fix it.

I see an immediate behavior change here

Woohoo! Very glad to hear that!

Apologies for this wild goose chase due to a messy config. If I'm in any place to make a suggestion, adding a UX interlock when switching models with that option on might be helpful "switched model to gpt-5.3-codex xhigh [red]but reasoning is disabled due to ... [/red]" would have been immediately helpful

Yeah, reasonable suggestion. We support hundreds of config keys, and all of of them are footguns to some degree. It's not feasible for us to report all potential misconfigurations as warnings, but we can check for the most common problems and add a warning.

In general, I recommend keeping your config as clean as possible. Don't override any setting unless there's a good reason to do so.

@qdbp, I looked at your logs and can confirm that the reasoning level sent to the model is null, which explains the behavior you're seeing. Now we need to determine why it's null. Do you have any other non-default overrides in your config file? For example, do you set model_supports_reasoning_summaries to false?

I had model_supports_reasoning_summaries set to false, not thinking it would force the model to stop reasoning.
Removing it from the config seems to have fixed my issue as well.

I've been facing the same problem here. Do you know if the issue has been tackled in the latest updated