CLI shows `fd --max-depth` values as search patterns

Start in codex-rs/shell-command/src/parse_command.rs at parse_fd_query_and_path, then inspect the existing fd_file_finder_variants test. Run the reproducible fd command and the codex-shell-command tests with just test and the dev-small profile. Done means depth-option values are excluded from search operands, the summary shows the actual pattern and path, and numeric search patterns still work.

What version of Codex CLI is running?

codex-cli 0.155.1 (latest stable release at the time of reporting). The parser omission is also present on current main at 78245b47af2a7aafcabe025828ceecca69db4df1.

What subscription do you have?

Not provided; the parser regression reproduces locally without a model request.

Which model were you using?

Model-independent command-summary parsing.

What platform is your computer?

Darwin 27.0.0 arm64 arm; fd 10.4.2.

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

Not recorded.

Codex doctor report

Relevant excerpt from codex doctor --json (unrelated checks and local paths omitted):

{
  "schemaVersion": 1,
  "codexVersion": "0.155.1",
  "overallStatus": "warning",
  "checks": {
    "installation": {"status": "ok", "summary": "installation looks consistent"},
    "config.load": {"status": "ok", "summary": "config loaded"},
    "runtime.provenance": {"status": "ok", "summary": "running brew on macos-aarch64"}
  }
}

The parser regression reproduces without a model request.

What issue are you seeing?

The compact CLI activity summary treats the value of an fd depth option as the search pattern and shifts the search directory to the wrong argument.

For example:

fd --max-depth 1 --type f -e py . repro/scripts

is summarized as:

• Explored
  └ Search 1 in .

Here, 1 belongs to --max-depth. The actual filename pattern is ., and the search root is repro/scripts. The shell command itself executes correctly.

What steps can reproduce the bug?

1. In a test directory, create a small fixture:

   mkdir -p repro/scripts
   touch repro/scripts/example.py
   

2. Ask Codex CLI to execute exactly:

   fd --max-depth 1 --type f -e py . repro/scripts
   

3. Compare the compact activity summary with the full command in the transcript.

What is the expected behavior?

Option values should not become search operands. With the existing summary format and path shortening, this command should display:

• Explored
  └ Search . in scripts

Additional information

The root cause is in parse_fd_query_and_path: the value-taking option list includes --type, --extension, and --exclude, but omits -d, --max-depth, --min-depth, and --exact-depth. Their values remain in the positional operand list.

https://github.com/openai/codex/blob/78245b47af2a7aafcabe025828ceecca69db4df1/codex-rs/shell-command/src/parse_command.rs#L1931-L1959

The core fix is limited to the option-value list:

diff --git a/codex-rs/shell-command/src/parse_command.rs b/codex-rs/shell-command/src/parse_command.rs
--- a/codex-rs/shell-command/src/parse_command.rs
+++ b/codex-rs/shell-command/src/parse_command.rs
@@ -1941,6 +1941,10 @@ fn parse_fd_query_and_path(tail: &[String]) -> (Option<String>, Option<String>)
             "--extension",
             "-E",
             "--exclude",
+            "-d",
+            "--max-depth",
+            "--min-depth",
+            "--exact-depth",
             "--search-path",
         ],
     );

A small local change adding these four options fixes the reproduced parser failure. Regression coverage extends the existing fd_file_finder_variants test for the depth options, attached values, and a genuine numeric search pattern (fd 1 --max-depth 2 repro/scripts). All 192 codex-shell-command tests pass using just test with the dev-small profile and Rust 1.98.1.

Related: #9079 also concerns misleading Search / Explored summaries, but involves a mutating pipeline rather than fd option values.