[macOS Desktop] Interactive exec PTY cannot be attached to user-visible terminal; open_in_codex reports success but opens a separate zsh

What version of the Codex App are you using (From “About Codex” dialog)?

26.915.31945

What subscription do you have?

Not provided

What platform is your computer?

Darwin 25.6.0 arm64 arm (macOS 26.6.2)

What issue are you seeing?

Summary

Codex Desktop starts a backend interactive PTY for a command waiting for user input, but opening the bottom terminal panel does not attach it to that process. The panel contains a separate interactive zsh. User input reaches that shell while the original command continues waiting.

Actual behavior

Entering ABC in the bottom panel runs it as a shell command and prints zsh: command not found: ABC. The backend read -s remains blocked. Desktop logs report success=true for open_in_codex, although the panel is not attached to the waiting PTY.

Impact

Any workflow in which a Codex-started process legitimately requires interactive user input cannot be completed through the Desktop managed-terminal UI. Examples include password prompts and other interactive CLI programs.

What steps can reproduce the bug?

1. Create a new Codex Desktop conversation.

2. Ask Codex to run this command in an interactive managed terminal:

   read -s "TEST_PASSWORD?Enter test password: "; echo
   

3. When it waits for input, ask Codex to enter nothing and show that same live TTY in the bottom terminal panel.

4. Codex reports that the command is waiting for input and that the terminal is open. The panel instead shows an ordinary interactive zsh.

5. Type ABC and press Enter in the bottom panel.

6. Observe zsh: command not found: ABC there, while the original read -s continues waiting.

This reproduces locally without SSH, network access, or any remote system.

What is the expected behavior?

The bottom terminal panel should be attached to the PTY running read -s. Typing ABC and pressing Enter should satisfy read and let the command finish, rather than executing ABC in another shell.

Additional information

Environment

• macOS 26.6.2, Apple Silicon (arm64)
• ChatGPT/Codex Desktop 26.915.31945
• Bundled Codex CLI 0.155.0-alpha.9.2

Process-level evidence

During reproduction, ps and lsof showed two distinct PTYs. The visible user terminal ran zsh -i; the backend interactive exec ran /bin/zsh -c read -s ... and remained blocked. Their stdin/stdout/stderr were attached to different /dev/ttys* devices. The Codex app-server held PTY masters via /dev/ptmx for both sessions. Actual PIDs and TTY numbers are omitted.

Relevant sanitized Desktop log events:

dynamic_app_tool_renderer_execution_started ... tool=open_in_codex
Sending server response ... success=true tool=open_in_codex

These lines show a successful tool response, not a successful attachment to the backend exec PTY.

Control test

Codex was asked to use the already visible interactive zsh and execute the command directly in that existing terminal, without creating a new exec/TTY session. Codex reported that its available tool could read that terminal's state but could not send input to that session.

Isolation performed

• Reproduced in a new conversation with a simple local read -s command.
• No SSH, network, NAS, or remote system was involved.
• Reproduction did not depend on restored conversation history.
• Ordinary non-interactive exec commands worked.

The observations suggest a problem in Desktop/app-server PTY attachment or open_in_codex handling. They do not establish an internal root cause.

No files, full logs, personal paths, credentials, network addresses, session IDs, or conversation contents are attached.

Start by reproducing the local read -s command and trace the Desktop/app-server open_in_codex PTY-handling path. Compare the PTY used by the backend interactive exec with the bottom terminal panel; done means the panel attaches to the waiting process so input completes read instead of running in a separate zsh.