Codex keeps reporting an error that isn't actually an error despite Framework MCP and Agents instruction.
What version of Codex is running?
0.77.0
What subscription do you have?
Business
Which model were you using?
gpt-5.2-codex, gpt-5.1-codex-max
What platform is your computer?
Darwin 25.1.0 arm64 arm
What issue are you seeing?
Codex keeps reporting this error
The new MyComponent is imported as a standalone component in MyModule and used directly in templates, but the component decorator does not declare standalone: true while still using the imports field.
Angular will fail compilation with “imports is only valid on a standalone component” / “component is not standalone” errors, preventing the app from building. Add standalone: true so it can be imported instead of being declared
in an NgModule.
When asking to codex to ask to the Angular MCP what is the default value the property it does
Called angular-cli.search_documentation({"query":"standalone default true Angular 20 decorator default standalone","includeTopContent":true})
└ No results found.
Called angular-cli.get_best_practices({})
└ .... - Must NOT set standalone: true inside Angular decorators. It's the default.
So Angular MCP is clear about this.
But when I start a new chat it completely forgot this rules and continue to report this as an issue.
I've event tried to add the Angular MCP instruction to my AGENTS.MD file Must NOT set standalone: true inside Angular decorators. It's the default in Angular v20+. but it doesn't stop to report it.
Even more troubling, it focuses on this anomaly while ignoring other, genuinely problematic ones.
I'm experiencing this issue with the gpt-5.2-codex and gpt-5.1-codex-max models, regardless of whether the reasoning level is Very High or Medium
What steps can reproduce the bug?
Uploaded thread: 019b6eaa-599e-7c01-b292-2869c52f253e
What is the expected behavior?
Codex needs to stop focusing on problems that aren't really problems and take the time to concentrate on real issues.
Additional information
I'm currently testing the daily use of AI agents for our development teams, so I'm still figuring things out when it comes to setting them up.
It's possible I don't fully understand what I'm doing and that I might make a beginner's mistake (because yes, I definitely am one), so please don't hesitate to tell me if I'm doing something wrong; I won't take it personally!
I use Codex CLI in /review mode and in "What can you tell me about component XXX?" mode, and this problem occurs in both modes.
In /review mode, the error that isn't actually an error is sometimes the only feedback I get, whereas in "What can you tell me about component XXX?" mode, it will also report other anomalies.
This completely defeats the purpose of /review mode for my case.
5 Comments
The
/reviewfeature generally does a good job finding relevant problems, but it is not infallible.Currently, the
/reviewfeature does not useAGENTS.mdor MCP servers. It effectively creates its own mini session within your primary session. The thinking behind this is thatAGENTS.mdtypically provides instructions for writing the code whereas/reviewis typically used at the end of a task, once the new code is written.Thanks @etraut-openai
It's true that, in general, this feature is effective and has highlighted some very interesting points lately;
But recently I've found it a little less relevant and, above all, focused on issues that aren't really issues, and it's precisely this evolution that I'm trying to understand.
Very interesting!
I mistakenly thought I could use
/reviewto both perform a functional review of the changes made and verify adherence to the team's practices, which I've documented in myAGENTS.md, among other things.But I also didn't assume that the review would only concern products created using Codex and therefore presumed to already comply with the guidelines in
AGENTS.mdand the MCP documentation.In fact, in my use case, I use
/reviewas a double-check beside of my own code review of pull requests from my team members.And while Codex
So this raises another questions for me
how is the knowledge base used in this mini-session structured?
To perform a code review on a project, I imagine it's important to know the project's context, the technologies it uses, and the specific features of the versions used.
For example, between a JavaScript, TypeScript, or C# project, you'll inevitably get feedback that's specific to each language.
But also, when is this knowledge base built?
During model training? If so, does it means that the
/reviewfunctionality will have a slight discrepancy between the "operational reality" and what it's capable of interpreting.This isn't a criticism; I completely understand that it might be a deliberate choice, but it's quite important to be aware of this in order to use it as intended.
It might be instructive to think about how traditional (human-based) code reviews work. It's good to have another person review your code because they can potentially spot bad assumptions that you have made when you designed and implemented the code. This requires the reviewer to understand the intent behind the change, but it's important for them to come at the review with a fresh perspective — to challenge the assumptions and decisions. That's why
/revieweffectively starts a new mini session when it's performing its review. If it were to use the same session — including all of the chain-of-thought reasoning tokens created by the model when it was implementing the change, it would not be looking at the problem with "fresh eyes". It would be analogous to you reviewing your own PR.I agree that having a fresh perspective is a key part of an effective review, and I see the analogy with avoiding self-review.
That said, I think it’s also worth considering how much contextual knowledge a reviewer should retain in order to be truly useful. In a team setting, a reviewer typically brings fresh eyes while still sharing a common understanding of the language, tooling, and team conventions.
From that perspective, artifacts like the agent files and the MCP feel less like implementation details and more like shared context: they exist to clarify how a feature is expected to be developed and what “correct” means within the team. Leveraging them during a review could help ensure not only that assumptions are challenged, but also that established guidelines and best practices are respected.
Maybe the interesting question here is where to draw the line between “fresh eyes” and “necessary context.” A review that combines a clean perspective with an awareness of the intended constraints might get closer to how effective human reviews work in practice.
I’m curious how you see that balance 🤔
This bug report hasn't received any upvotes or additional posts in three months. Closing.