Codex CLI loves to use stubs, shims, fallbacks, placeholders as default approaches

Resolved 💬 2 comments Opened Nov 13, 2025 by 3SMMZRjWgS Closed Nov 13, 2025

What version of Codex is running?

0.57.0

What subscription do you have?

ChatGPT-Pro

Which model were you using?

GPT-5 high

What platform is your computer?

Windows 11 Pro

What issue are you seeing?

For some reason, every model within Codex CLI family loves to use stubs, shims, placeholders—basically fake stuff that plugs a place and then allows things to keep moving and report results as if they're real. But then you have to call it out and say, well, did it actually work? And then it will say something like, oh, I didn't actually use the model to backtest. Sorry, do you want me to? That just seems to be very annoying, inefficient, and pointless behavior.

So between wanting to use whatever shims to sandwich between old and new code, leaving the legacy code in place, and wanting to keep fallbacks, all of these behaviors seem to be really hard to steer, even when I've noted in multiple places saying: do not do these, do not fall back, do not keep legacy code, do not use placeholders and plugs and all that, the model still steers towards that behavior. Is there a way that we can at least allow users who choose not to have such behavior to be able to steer it? It's so annoying to have to constantly fight this behavior, call it out, inspect it, and then correct it. It adds significant agentic coding efficiencies. If something breaks, let it break, so it can surface and be fixed. If it just hides it with all the fake plugs, it becomes very problematic for the developer to have to surface every one of those hideouts then ask Codex CLI to correct.

This behavior tends to increase when Codex CLI is dealing with very new and advanced algorithms. It appears to be some kind of self-protection mechanism that if the certainty of knowledge is lower, it behaves more defensively trying to avoid being seen as being wrong. But that behavior itself creates greater chance to be wrong if the human developer can't catch the plugs/shims/fallbacks.

What steps can reproduce the bug?

Refer to thread ID 019a7b6f-2a77-70f2-bbe8-738d83061636

What is the expected behavior?

It codes like a human developer does, it codes for reals using real data, models, APIs, and then fail, and then correct it, then try again until it succeeds.

Additional information

_No response_

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗