Codex Desktop background/worktree tasks can report command success without a Host-observable command execution item

Summary

A Codex Desktop coordinator can create an independent background or worktree task, ask it to run a concrete test command, and receive a final message that reports success and an exit code even though the coordinator-visible Host readback contains no command execution item at all.

This creates an evidence gap: the model's final text says the command ran, but the Host surface provides no independently observable command record or real exit code.

Environment

• Product: Codex Desktop on macOS
• Model used for the independent task: gpt-5.6-sol
• Surfaces exercised: local background task and isolated worktree task
• Readback flow: create task, wait for completion, then read the completed task with outputs included
• The worktree reproduction used a real committed Git revision, so worktree creation itself succeeded

Reproduction

1. From a coordinator task, create an independent gpt-5.6-sol task in a local project or isolated worktree.
2. Give it a narrow, read-only instruction such as:

``text
Run exactly: node --test test/tl06-real-app.test.js
Report the real process exit code and test counts. Do not modify files.
``

1. Wait until the independent task reports completion.
2. Read the completed task with output items included.
3. Compare the final text with the Host-issued items.

Actual behavior

Across both local-task and isolated-worktree reproductions:

• the final assistant message reported exit code 0 and passing test counts;
• the task readback contained only the user message and assistant message;
• there was no command execution item, tool call, command output, or Host-issued exit code;
• the latest tool marker was absent.

Therefore the coordinator cannot distinguish a real command execution from an unsupported or model-only claim.

This report does not assert that no process ran internally. It asserts that the supported coordinator readback did not expose any Host-observable execution evidence, while the final text nevertheless claimed successful execution.

Expected behavior

One of these fail-closed contracts should hold:

1. If the independent task executes the command, completed-task readback exposes a Host-issued command execution observation containing at least:

• command identity or a safely bounded representation;
• completion status;
• real process exit code;
• a stable item/event identity.

1. If command execution is unavailable to that task, the task must report an explicit typed unavailability result and must not claim that the command ran or that an exit code was observed.

A model-authored final message should not be the only evidence for an external side effect such as command execution.

Impact

Coordinator workflows cannot safely use independent tasks for test verification, build verification, or other command-backed acceptance gates. Treating the final message as execution evidence can produce false-positive closure; rejecting it means the Host integration cannot complete despite the task reporting success.

Duplicate search

I searched open and closed issues in openai/codex for combinations of:

• read_thread and commandExecution
• create_thread and includeOutputs
• background/worktree task plus tool call or command execution
• delegated task reporting command success without a tool call

The closest results concern thread-management tools being unavailable, tasks stalling after real tool results, or tool-call failures. Those are adjacent but do not cover a completed independent task whose final reports command success while coordinator readback has no execution item.

Related but distinct: #30233 concerns thread-management tools not being exposed at all.