Desktop terminal tools: ambiguous session IDs and unconditional queued result lead to false attachment diagnosis

Desktop terminal tools: ambiguous session IDs and unconditional queued result lead to false attachment diagnosis

Summary

In ChatGPT Desktop 26.901.51231, open_in_codex accepts a stringified session ID returned by exec_command, reports success with status: "queued", and selects a separate integrated-terminal record instead of attaching to the running exec process. There is no tool-visible explanation of the session-ID mismatch or final opening result.

This is related to terminal troubleshooting in #31417, but this report does not establish a recurrence of its original permanent/client thread-ID bug. Integrated-terminal reading passed: the user ran a unique printf marker in the visible shell, and an independent read_thread_terminal call returned the marker output and subsequent zsh prompt. The reproducible problem is the ambiguous tool contract and missing validation/feedback.

Environment

• ChatGPT Desktop: 26.901.51231, bundle build 8109
• Bundled Codex CLI: 0.153.4
• macOS: 26.6.2 (25G83), Apple Silicon arm64
• Local desktop task, zsh integrated terminal
• Date tested: 2026-09-07

Reproduction

1. Open an integrated terminal in a local task.

2. Ask the agent to call read_thread_terminal. In this case it returns the task directory, shell: zsh, and an idle shell prompt.

3. Start an agent-owned interactive exec process, keeping it alive while testing. For example, use exec_command with Bash, tty: true, login: false, and this command:

   printf 'CODEX_EXEC_ATTACH_PROBE\n'
   read -r -t 120 probe_reply
   printf 'CODEX_EXEC_RECEIVED:%s\n' "$probe_reply"
   

4. Take the numeric session_id returned by exec_command and pass its string form to:

   {
     "target": { "type": "terminal", "sessionId": "<exec-session-id>" },
     "placement": "bottom"
   }
   

5. open_in_codex returns success with:

   { "status": "queued", "threadId": "<current-thread-id>" }
   

6. Call read_thread_terminal again. In this run, the snapshot changed to:

   App terminal snapshot for this thread:
   cwd:
   shell: unknown
   [terminal has no output yet]
   

   This empty/unknown snapshot was returned on three successive reads. It did not contain the exec marker.

7. Send ASTRA_INPUT_OK\n through write_stdin to the original numeric exec ID. The agent-owned process correctly returns CODEX_EXEC_RECEIVED:ASTRA_INPUT_OK and exits. Its input/output works independently of the integrated terminal.

8. Reopen the previously existing app-terminal ID through open_in_codex. It still returns queued, but read_thread_terminal returns the original zsh prompt again.

The persisted routes gained a separate terminal:<exec-session-id> entry during the test. No profile reset or app-bundle modification was involved.

Expected Behavior

• Define the namespace and source of target.sessionId: an app-terminal ID, exec process ID, command-execution item ID, or another identifier.
• Reject an unsupported/unknown ID with an actionable error before changing the active terminal or creating a persisted route. Alternatively, explicitly support attaching an exec process.
• Return the actual opened/existing result when available, or expose a completion/error status for queued requests.
• Make the tool description clear that queued alone is neither proof of failure nor proof of attachment.

Implementation Evidence

Read-only inspection of the installed bundle found:

• In webview/assets/app-initial-cadb12d4a15e.js, the open_in_codex handler (qvi in this build) returns queued after successful dispatch/enqueue regardless of whether the target task is already visible. Its description singles out hidden tasks as returning queued, which encourages the wrong diagnostic inference.
• In webview/assets/open-in-codex-830d035377f0.js, runWindowsTabsOpen computes opened or existing and the resulting tab ID. The agent-facing wrapper does not expose that result.
• In webview/assets/runtime-6d24aecca513.js, the terminal opener (M in this build) adds an explicit unknown session ID to the app-terminal conversation registry and activates it. That branch does not resolve a unified-exec process ID.
• The current read_thread_terminal result contains cwd, shell, and buffer, but no terminal session ID or snapshot timestamp. That makes it harder for the agent to verify exactly which tab it is reading.

Suggested regression checks: visible-task opens, hidden-task completion, valid app-terminal IDs, unknown IDs, unified-exec IDs, and active-tab preservation after rejected IDs.

Scope and Limitations

This report does not claim all integrated-terminal reads are broken or that agent keystroke input into a user-owned terminal is a documented feature. Deliberate marker-command execution in the visible shell was independently verified by the terminal read tool. A post-restart/fresh-task retest was not completed. The installed bundle was inspected, not patched.

The two-root "Source directories" display is a separate UI hint. Its implementation hides it after user input; it is not shell startup output or evidence of attachment failure.

Related issue: https://github.com/openai/codex/issues/31417

Documentation: https://learn.chatgpt.com/docs/integrated-terminal

No passwords, personal paths, full task IDs, raw logs, or screenshots are included in this draft.

Start by tracing the open_in_codex handler in webview/assets/app-initial-cadb12d4a15e.js and the tab result handling in webview/assets/open-in-codex-830d035377f0.js. Compare that behavior with the terminal opener in webview/assets/runtime-6d24aecca513.js, then run the suggested checks for visible and hidden tasks, valid and unknown IDs, unified-exec IDs, and active-tab preservation.