GPT-5.6 Terra abandons yielded exec_command sessions after ~10s and attempts duplicate commands

What version of Codex CLI is running?

codex-cli 0.144.5

What subscription do you have?

ChatGPT Pro

Which model were you using?

gpt-5.6-terra, high reasoning effort

What platform is your computer?

Linux x86_64

What issue are you seeing?

GPT-5.6 Terra does not reliably preserve ownership of an exec_command after the command crosses the default ~10 second yield boundary and becomes a background terminal.

In a minimal reproduction using two one-minute sleeps, Terra:

1. Started the first sleep 1m.
2. Correctly acknowledged that the first terminal was still running.
3. Later stated that the first sleep had completed, without first observing completion through write_stdin.
4. Attempted to start the second sleep 1m with a new exec_command while Codex still considered the first Bash session active.
5. A local serialization PreToolUse hook blocked the second command and returned: Another Bash command is still running for this Codex session. Continue polling that terminal with write_stdin until it exits.
6. Only after receiving that rejection did Terra poll/close the original terminal and then start the second sleep.

The hook prevented actual overlap, but it proves that Terra inferred or fabricated process completion and attempted a duplicate command while the original Codex terminal session remained live.

In normal use without this guard, the same failure pattern results in 3–4 background terminals running the same build/test command.

Steps to reproduce the bug

1. Use Codex CLI 0.144.5 with gpt-5.6-terra at high reasoning effort.
2. Ask: run one sleep 1m.
3. Before or shortly after it yields, ask again: run one sleep 1m.
4. Observe whether Terra continues polling the original session_id with write_stdin until a terminal result is returned.
5. In the uploaded reproduction, Terra instead claimed completion and attempted a new exec_command while the previous session was still active.

A serialization hook was installed only to make the race observable and prevent duplicate process execution. write_stdin remained allowed, while a new Bash/exec_command was blocked if the existing session lock was still held.

Expected behavior

Once exec_command returns a live session_id, Codex should maintain a deterministic invariant:

• the model must continue that same session through write_stdin, or
• the runtime should wake the thread when the process exits, or
• the process must be explicitly detached/abandoned before another foreground command may start.

The model should never report that a process completed unless a terminal result with an exit status was actually observed.

A new exec_command should not be started while the previous serialized foreground process is still live.

Why this appears GPT-5.6-specific

The same long-running workflows are reliable for me with GPT-5.5 medium. Both GPT-5.6 Terra and Sol frequently lose the yielded terminal session, treat it as detached or completed, and start the command again.

Commands finishing inside the initial synchronous window generally work. Reliability drops sharply once the command lasts longer than the default yield_time_ms = 10000 and requires session continuation through write_stdin.

Uploaded thread

019f6cfe-82b5-7823-9310-33d871096ac5

The uploaded feedback contains the complete minimal session and screenshot.

Related issues

• #14731 — turn completes while unified-exec background processes are still running
• #15723 — background subprocesses do not wake the calling agent
• #13733 — repeated write_stdin polling wastes full model turns
• #32188 — event-driven wakeup when background exec sessions complete

This report is specifically about the GPT-5.6 model-side consequence: losing the live session invariant, falsely asserting completion, and attempting duplicate command execution.