Codex CLI does not attempt to open referenced files before reasoning

What version of Codex CLI is running?

codex-cli 0.107.0

What subscription do you have?

Plus

Which model were you using?

_No response_

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What terminal emulator and version are you using (if applicable)?

PowerShell

What issue are you seeing?

I’m using Codex CLI in a workspace-aware context for real code work.

In a recent session, I explicitly referenced a specific file (e.g. categories.class.php) and a specific method (e.g. get_category_list()) while asking an architectural question. Codex did not attempt to open the file or confirm it had access to it. Instead, it responded with abstract, generalized advice.

This is a serious workflow issue.

When a user references a specific file and method in a coding context, that is a clear signal that the actual implementation details matter. A coding agent should either:

1. Attempt to open and read the referenced file before reasoning, or
2. Explicitly state that it cannot access the file and request its contents.

Proceeding with abstract reasoning without grounding in the referenced code breaks trust. It creates risk of incorrect architectural guidance and wastes engineering time.

If Codex CLI is positioned as a coding agent (not just a code-trained language model), then file references should trigger automatic grounding behavior.

At minimum:

• Detect file references.
• Attempt to locate and open them in the workspace.

If unsuccessful, explicitly state that the file could not be accessed.

Silent abstraction in this scenario undermines confidence in the tool for real engineering work.

What steps can reproduce the bug?

1. Navigate to a Git repository directory containing a PHP file (e.g., categories.class.php).
2. Launch Codex CLI from the repository root
3. Provide a prompt that explicitly references a specific file and method within the repo, for example:

I have a class categories.class.php.
The method get_category_list() builds category icon URLs dynamically.
What is the best architectural approach to prevent broken images if the icon file does not exist?

Observed behavior:
Codex provides abstract architectural guidance without attempting to:

• Open the referenced file
• Confirm it has access to the file
• Quote any relevant code
• State whether the file could not be accessed

What is the expected behavior?

When a specific file and method are explicitly referenced in a workspace-aware CLI session, Codex should:

• Attempt to locate and open the file before reasoning, OR
• Explicitly state that it cannot access the file and request its contents

Proceeding with ungrounded advice in this context undermines trust in Codex as a coding agent.

Additional information

_No response_