GPT-5.6 consistently aborts functions.exec / tools.exec_command, while GPT-5.5 works

Open 💬 2 comments Opened Aug 12, 2026 by FPbear

What version of Codex CLI is running?

codex-cli 0.147.0

What subscription do you have?

Enterprise

Which model were you using?

_No response_

What platform is your computer?

_No response_

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

_No response_

Codex doctor report

What issue are you seeing?

Summary

functions.exec consistently returns aborted when running shell commands with GPT-5.6 models, while the same operation works normally with GPT-5.5.

Reproduction

Run a minimal shell command:

echo hello

The tool call immediately returns:

aborted

No command output, stderr, or exit code is returned.

The issue is reproducible with other trivial commands, including:

pwd
echo hello
python3 --version

It also occurs when invoking the nested JavaScript tool:

const r = await tools.exec_command({
  cmd: "echo hello",
  yield_time_ms: 10000,
  max_output_tokens: 2000
});
text(r.output);

The execution is still aborted before any command output is produced.

Expected behavior

The command should execute successfully and return:

hello

Actual behavior

The execution is aborted before the command produces any output.

There is no stdout, stderr, or exit code returned by the tool call.

Model comparison

  • GPT-5.5: works normally
  • GPT-5.6: consistently returns aborted
  • GPT-5.6-terra: consistently returns aborted

The same Codex CLI installation and environment are used for the model comparison.

Additional observations

  • The failure occurs with trivial local commands that do not require network access or special permissions.
  • echo hello reproduces the issue, so the failure does not appear to be related to Python, Git, or the repository.
  • Changing the working directory, shell options, and command arguments does not resolve the issue.
  • Switching to GPT-5.5 immediately restores normal command execution.
  • The behavior is consistently reproducible with GPT-5.6 models.

This appears to be a model-specific issue in the tool execution path rather than a failure of the underlying shell command.

Environment

  • OS: macOS
  • Codex CLI: 0.147.0
  • Tool: functions.exec / tools.exec_command
  • Model: GPT-5.6 / GPT-5.6-terra
  • Working directory: local Git repository
  • Architecture: Apple Silicon

Minimal reproduction

Codex CLI 0.147.0
Model: GPT-5.6-terra

User: Run `echo hello`

Tool: functions.exec
Result: aborted

No stdout
No stderr
No exit code

Switching only the model:

Codex CLI 0.147.0
Model: GPT-5.5

User: Run `echo hello`

Tool: functions.exec
Result: hello

The difference is consistently reproducible.

What steps can reproduce the bug?

  1. Install and run Codex CLI 0.147.0 on macOS (Apple Silicon).
  2. Open a local Git repository with Codex.
  3. Select the GPT-5.6-terra model.
  4. Ask Codex to execute a trivial shell command, for example:

``sh
echo hello
``

  1. Observe that the functions.exec / tools.exec_command call immediately returns aborted.
  2. No stdout, stderr, or exit code is returned.
  3. Repeat with other trivial commands such as:

``sh
pwd
python3 --version
``

The same behavior occurs.

  1. Switch the model to GPT-5.5 and run the same commands.
  2. Observe that the commands execute normally and return their expected output.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

2 Comments

FPbear · 15 days ago

Update

I downgraded Codex CLI from 0.147.0 to 0.146.0 and retested the same GPT-5.6-terra model.

With Codex CLI 0.146.0, GPT-5.6-terra can execute shell commands normally.

Updated model/version comparison

| Codex CLI | GPT-5.5 | GPT-5.6-terra |
|---|---|---|
| 0.147.0 | Works | aborted |
| 0.146.0 | Works | Works |

For example, with 0.146.0 + GPT-5.6-terra:

echo hello

returns the expected output:

hello

This suggests the issue is specific to Codex CLI 0.147.0 when used with GPT-5.6-terra, rather than an issue with GPT-5.6-terra itself.

The issue is reproducible on 0.147.0 and resolved after downgrading to 0.146.0.

jdcodes1 · 9 days ago

The literal string aborted pins down where this comes from: it is codex's synthetic placeholder, injected by history normalization when a tool call has no recorded output — ensure_call_outputs_present inserts FunctionCallOutputPayload::from_text("aborted") for any call whose result never landed (https://github.com/openai/codex/blob/1f41cc5d92/codex-rs/core/src/context_manager/normalize.rs#L48-L63). So the command isn't being cancelled; its output is being lost before it enters history, and the model then sees the placeholder.

The model/version matrix fits the code-mode routing change: in 0.147 the GPT-5.6 family runs exec through code mode (ToolMode::CodeMode, feature-gated per model via managed features — core/src/tools/mod.rs#L74-L76), i.e. through the standalone codex-code-mode-host process, while GPT-5.5 uses the classic direct path. #38417 reports that exact host crashing with SIGTRAP on every shell exec on 0.147.0 (0.146.1 fine). A host that dies mid-call produces no output → "aborted" placeholder, no stdout/stderr/exit code — precisely your symptom, and consistent with tools.exec_command (also host-routed) failing identically.

Worth checking to confirm: platform (the #38417 crash is Linux/WSL2) and whether codex-code-mode-host crash lines appear in $CODEX_HOME/log/ during a failing call. If confirmed, this is a duplicate-by-mechanism of #38417 with the placeholder string as the visible symptom.