I Codex, but have run into a single problem that I just can’t seem to prompt around.
Specifically, I am working in a codebase that uses tabs and not spaces. No matter what I put in the AGENTS.md file or the other markdown documentation, it just refuses to use tabs instead of spaces. I put it in multiple places. I used asterisks. I’ve used capitals and it still won’t default to tabs.
When providing feedback on each PR, I can often have it fix the mistake while I point to the code styling documentation, so it definitely knows how to do it, but even then it sometimes misses places.
I’m at a loss. Any tips from others in similar codebases?
I had a “no duh” moment this past weekend on this one. I haven’t tried it just yet, but wanted to share – add a linter.
I think if I just add a linter and tell Codex to always use the linter before submitting code, it will eliminate the lack of clarity for it around tabs vs. spaces because the linter will return clear errors that it will need to fix, particularly if the linter can auto-correct the spaces and replace them with tabs. I’m almost certain this will work, but adding the linter will take a little bit, so I didn’t want to wait before posting.
So it turns out that Codex sort of sucks at adding my linter and running it only on newly generated files even when I prompt it to be that focused. Not to mention I have file types in this repo that there aren’t really linters for.
So it would be REALLY nice if Codex just, you know, followed instructions on tabs vs. spaces. That would save a lot of pain.
Sorry you had to interact with an AI response above, pretending to be a human that actually has insight.
Ironically, you can’t stop the API AI models from making tabs when using structured outputs. Equally frustrating.
On the API, it is also impossible to demote the production of spaces (a three-space token is typically used in Python code, then an additional leading-space token with the content). The codex-mini-latest is only provided on the Responses endpoint, despite that it is Chat Completion’s logit_bias parameter that could allow you to make tabs more likely.
I suggest a PR for the whole repo: “converting the code base to 4-space indentation to match PEP8 and expected coding practices”, that you can do programmatically.
I have an extensive ESLint configuration. The project that creates the config file is a part of the repo in the /vendor folder as a .tgz, and added as a devDependency.
My AGENTS.md instructions tell the assistant to generate a lint and save the output to a temp file. Then after it’s made changes, to lint again with output to another file. With a diff on the files it can see if it created any new issues. The instructions tell it to use the diff to fix only those new issues.
If your linter specifies tabs and not spaces, the assistant needs to go through that specific process to fix the problem. Will it get into an infinite loop as it attempts to replace spaces with spaces rather than tabs? Let’s find out.
My instructions also emphasize that the assistant must not take initiative to fix original linting issues. Without that it tries to get way too helpful and really goes on tangents to find and fix anything it can. This also compels me to check linting before my own pushes, so that it doesn’t have anything to distract it.
Codex, but have run into a single problem that I just can’t seem to prompt around.