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

Open 💬 3 comments Opened Jul 17, 2026 by sa6mwa

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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:

Started the first sleep 1m.
Correctly acknowledged that the first terminal was still running.
Later stated that the first sleep had completed, without first observing completion through write_stdin.
Attempted to start the second sleep 1m with a new exec_command while Codex still considered the first Bash session active.
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.
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

Use Codex CLI 0.144.5 with gpt-5.6-terra at high reasoning effort.
Ask: run one sleep 1m.
Before or shortly after it yields, ask again: run one sleep 1m.
Observe whether Terra continues polling the original session_id with write_stdin until a terminal result is returned.
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.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#33712

Powered by Codex Action

sa6mwa · 1 month ago

This is related to, but not an exact duplicate of, #33712.

#33712 concerns a process that actually exits while the thread is idle and does not wake the model. This report concerns GPT-5.6 Terra asserting completion without observing an exit result and attempting a new exec_command while the original Codex terminal is still registered as live, as proven by the serialization hook.

The missing wakeup may be an underlying contributor, but the false-completion and duplicate-execution behavior is the model-specific regression reported here.

sa6mwa · 6 days ago

Update after more extensive testing:

I have now been running codex-cli 0.150.0-alpha.2 with gpt-5.6-terra at high reasoning effort for essentially a full day across multiple repositories and several long-running Goals. So far the behavior has been consistently good: no duplicate foreground command launches, no abandoned terminal sessions, and no cases where a live terminal was restarted because the model thought it had been lost.

The most important change on my side was disabling the agent subsystem entirely:

[agents]
enabled = false

[features]
multi_agent = false
collaboration_modes = false
enable_fanout = false

After restarting Codex with that configuration, both of the workflows that had previously exposed the problem became reliable:

Long-running make release / build commands. These had previously been enough to trigger the original failure mode: Codex would eventually lose track of an outstanding terminal, infer that it was gone or complete, or start another foreground command while the first was still alive. With agents disabled, long release/build commands are now completing consistently with a single outstanding terminal and no duplicate launches.

Nested codex review execution. In this workflow the parent Codex process starts codex review as an ordinary command, with explicit -c overrides for the review model/reasoning configuration. With agents enabled, GPT-5.6 could remember that it had started codex review but then misclassify that outstanding work as a subagent and call wait_agent, even though there was no subagent and the actual outstanding resource was a terminal process. With agents disabled, it behaves as expected: one background terminal is shown, codex review runs there, Codex waits for the process rather than entering agent polling, and execution resumes when the command completes.

I have seen this remain stable across multiple repositories, multiple Goals, long make release runs, and review cycles lasting multiple hours today, without a single recurrence so far.

The interesting part is that disabling agents appears to improve not only the codex review case, where there was an obvious terminal-vs-agent classification ambiguity, but also ordinary long-running make release commands. That suggests the failure is not simply specific to the codex review command name, and not simply "GPT-5.6 cannot supervise a long-running terminal process." There appears to be some interaction between the multi-agent lifecycle/tool surface and terminal lifecycle supervision more generally. Removing the agent control plane has, so far, made the process-based workflow reliable.

I do not want to claim this proves the underlying issue is fixed, and I have not isolated which 0.148/0.149/0.150 runtime changes may also be contributing. But compared with the original reproduction, 0.150.0-alpha.2 + agents disabled is a substantial practical improvement and currently works reliably for the same long-running Goal/build/review workload that previously reproduced the problem.