Feedback: GPT-5.6 task-following reliability in Codex

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #35131
• #35130
• #35035
• #34095

Powered by Codex Action

I am seeing the same general regression with GPT-5.6, but for me it goes beyond stopping early.

I use Codex regularly for real software development, both professionally through Azure/OpenAI models and personally through my ChatGPT Plus subscription, and I have observed the same change in behavior in both environments.

The main regression I notice compared with GPT-5.4 and earlier OpenAI reasoning/coding models is requirement tracking and task adherence.

With previous models, I could provide a long prompt containing many independent changes:
( for example several frontend changes, backend changes, validation rules, API changes, etc.) and Codex was remarkably reliable at working through every explicit requirement. When the result was wrong, it was usually because I had specified something incorrectly or ambiguously.

With GPT-5.6, I increasingly see the opposite pattern:

• Some explicit user requirements are silently forgotten or left unfinished.
• At the same time, the model invents implicit requirements, constraints, risks, or prerequisites which were never requested.
• Those invented concerns consume reasoning and implementation effort and sometimes become more important to the model than the actual task.

Two recurring examples are particularly noticeable.

1. Unrequested backward compatibility and migration work

GPT-5.6 very often behaves as if every repository were a legacy production system.

Even in projects that are explicitly still under development, with no production deployment and no production data, it tends to anticipate backward compatibility, transitional database schemas, migrations, preservation of old interfaces, etc.

I have tried explicitly documenting in "AGENTS.md" that breaking changes are acceptable and that there is no production data to preserve. This helps sometimes, but the model periodically falls back to the same assumptions anyway.

The issue is not that backward compatibility is inherently bad. The issue is that a generic software-engineering heuristic appears to override repository-specific and user-provided context.

1. Security/secret-management scope drift

GPT-5.6 also seems much more eager to introduce secret-management concerns even when they are irrelevant to the requested task.

It may start reasoning about secret rotation, revocation, storage policies, exposure risks, environment management, etc., despite none of those being part of the problem being solved.

I am not asking for weaker secret handling. The problem is that these heuristics are often insufficiently conditioned on task relevance.

This consumes reasoning budget, introduces constraints that do not exist, and distracts the agent from explicit requirements. In practice, the ironic result is that the model spends more effort protecting against hypothetical problems while occasionally forgetting real tasks that were explicitly requested.

The underlying regression

The best way I can summarize what I am observing is:

GPT-5.6 appears more willing to invent and satisfy implicit constraints, while becoming less reliable at exhaustively satisfying the explicit constraints supplied by the user.

Or, from an agent perspective:

Higher apparent agentic sophistication, but lower end-to-end requirement closure.

This is particularly frustrating because instruction following was one of the properties I valued most in OpenAI models since the o1 generation. I never maintained personal benchmarks for it because it had been consistently reliable enough that I considered it an established capability.

I unfortunately do not have the original prompts and repositories available to share: many of these observations occurred during normal work on private projects. I am going to start preserving reproducible cases and building a small regression suite for future model versions.

For future reports I should therefore be able to provide concrete comparisons and test cases. But I wanted to report the qualitative regression now because it has been consistent enough across unrelated projects and environments to noticeably affect my daily workflow.

A coding agent that solves 12/12 requested changes without unnecessary work is considerably more useful to me than one that demonstrates more sophisticated planning or agentic behavior but completes only 9/12 because it spent part of its effort solving problems I never asked it to solve.