gpt-5.6-sol xhigh dropped the git executable while constructing basic shell probes

What version of Codex CLI is running?

codex-cli 0.144.4

What subscription do you have?

ChatGPT Pro ($200/month tier)

Which model were you using?

gpt-5.6-sol with reasoning effort xhigh

What platform is your computer?

Linux 6.8.0-134-generic x86_64 x86_64

What terminal emulator and version are you using?

tmux 3.6a with TERM=tmux-256color, running under X11

Codex doctor report

codex doctor --json completed successfully with overallStatus "ok". The full report is omitted from this public issue because it contains unnecessary local-environment metadata. The uploaded thread contains the decisive tool-call trace.

What issue are you seeing?

During an important repository-resumption task, Codex intended to run these basic read-only Git probes:

~~~bash
git status --short --branch
git branch --show-current
git log -1 --oneline --decorate
~~~

Instead, it invoked:

~~~bash
status "--short" "--branch"
branch "--show-current"
log "-1" "--oneline" "--decorate"
~~~

The shell correctly returned "command not found" for those executable names. No mutation occurred.

The malformed commands were produced by a JavaScript batching wrapper generated by the assistant. The relevant structure was:

~~~javascript
const cmds = [
["git", ["status", "--short", "--branch"]],
["branches", ["branch", "--show-current"]],
["head", ["log", "-1", "--oneline", "--decorate"]],
// additional probes
];

for (const [name, args] of cmds) {
const cmd =
args[0] === "bash"
? args[2]
: args[0] + " " + args.slice(1).map(JSON.stringify).join(" ");
// execute cmd
}
~~~

The outer tuple value was treated only as an output label. For the Git entries, the inner array began with the Git subcommand rather than the "git" executable, so the wrapper silently dropped "git" from every generated command.

This was not caused by a shell alias, Git configuration, repository hook, or project orchestration layer. Re-running complete explicit Git commands worked normally.

What steps can reproduce the bug?

Uploaded thread: 019f66bb-1f0c-74f2-abe4-0dbdefe82ccf

This has been observed once and is not known to be deterministically reproducible:

1. Run Codex CLI 0.144.4 on Linux.
2. Select gpt-5.6-sol with xhigh reasoning effort.
3. Resume a context-rich repository task containing substantial project instructions.
4. Ask Codex to inspect repository state before continuing.
5. Codex may choose to batch multiple shell probes through a generated JavaScript wrapper and construct commands inconsistently.

The uploaded thread preserves the exact prompt, model configuration, tool call, malformed generated commands, shell results, and the assistant's subsequent diagnosis.

What is the expected behavior?

Codex should emit complete explicit commands for simple operational probes:

~~~bash
git status --short --branch
git branch --show-current
git log -1 --oneline --decorate
~~~

If Codex chooses to generate commands programmatically, it should use one consistent command representation and validate the final executable strings before invoking the shell.

Higher reasoning effort should not make basic tool construction less reliable. A missing executable in a mutating command could have materially worse consequences than the harmless read-only failures observed here.

Additional information

The model's performance in other work had been exceptional, including at medium reasoning effort. This incident was reported because the failure was unusually fundamental, occurred at xhigh reasoning effort during high-importance work, and has a complete uploaded trace suitable for diagnosis.

In the same short sequence, the assistant also guessed another CLI subcommand's argument contract incorrectly before correcting it. That secondary event may help maintainers assess whether the problem was isolated string composition or a broader temporary degradation in tool-invocation discipline.