Codex App: terminal on a remote Windows host flashes and closes; remote launcher assumes sh

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

Windows package: 26.903.9818.0, identified from the running application's installation path:
OpenAI.Codex_26.903.9818.0_x64__2p2nqsd0c76g0.

Both the local app-server and the last logged version of the remote Windows app-server are 0.153.4.

What subscription do you have?

Not included in this report.

What platform is your computer?

Client: Microsoft Windows NT 10.0.26200.0 x64.

Remote host: Windows, connected through Codex Remote Control. The remote Windows OS build has not been collected.

What issue are you seeing?

When I try to create an integrated terminal for a project on a remote Windows machine, the terminal panel appears briefly and immediately disappears. No usable terminal remains, and no persistent error message is shown. Repeating the action reproduces the behavior.

The remote host continues to respond: the client logs show successful remote activity and MCP startup status ready around the attempted reproduction. The client logs did not expose a terminal-specific startup error that could be tied to the attempt.

A read-only inspection of the installed desktop bundle found a likely explanation: the remote terminal launcher unconditionally uses sh -c and a POSIX login-shell script, while sh is not available in the remote user's PowerShell session. The error/exit handling can then remove the terminal session without preserving a visible error.

The missing-shell cause is strongly suggested, but is not yet confirmed by a captured process-spawn error or by inspecting the actual app-server process's PATH.

What steps can reproduce the bug?

1. Use the Windows Codex App and connect to another Windows computer through Codex Remote Control.
2. Open a project/task hosted on that remote computer, using a native Windows workspace path.
3. Try to create an integrated terminal.
4. Observe the terminal panel appear and immediately disappear.
5. Repeat: no terminal stays open.

On the affected remote host, I ran this in PowerShell:

Get-Command sh,bash,pwsh,powershell -ErrorAction SilentlyContinue |
    Select-Object Name,Source

Output:

Name           Source
bash.exe       C:\WINDOWS\system32\bash.exe
pwsh.exe       C:\Program Files\PowerShell\7\pwsh.exe
powershell.exe C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe

There is no sh entry. The presence of bash.exe does not make a command named sh available.

What is the expected behavior?

• Select a shell appropriate to the remote operating system, such as PowerShell on a native Windows host, and respect the remote shell configuration.
• Keep a successfully started terminal open.
• If spawning the shell fails, keep the panel open with an actionable error that identifies the attempted executable and failure.
• Record terminal startup failures in the desktop logs so they can be diagnosed.

Additional information

The following findings come from read-only inspection of the installed app.asar; the application and remote machine have not been modified.

In .vite/build/main-CMBCj4XL.js:

• createTerminalBackend routes remote host configurations to createRemoteTerminalBackend.
• createRemoteTerminalBackend obtains its command from Lle(), starts it with tty: true, and sets shellKind: "posix".
• Lle() returns ["sh", "-c", <login-shell script>]. That script checks SHELL, optionally queries getent passwd, falls back to /bin/bash, and executes the selected shell with -il.
• The remote branch does not call resolveTerminalCommand, which the local branch uses to select its configured shell.
• The remote backend converts a rejected process-session promise into an exit event carrying an error.

In webview/assets/app-initial-f094ef01c64d.js:

• handleHostEvent handles exit and error.
• Outside the error-preservation branch conditioned on a workspace binding's environmentId, it can call deleteSessionMapping, removing the session and its UI state.

In webview/assets/terminal-panel-e2350b6eaef2.js:

• The panel's session listener registration includes onInitLog, onData, and onAttach, but no onError or onExit callback.

This combination appears consistent with a startup failure becoming a disappearing terminal panel instead of a visible error.

Useful regression coverage would include a remote Windows host with PowerShell available and no sh in PATH, plus a failed shell spawn whose diagnostic remains visible.

Related reports found during duplicate search: #25256 and #29090 describe a similar panel-flashing symptom. This report adds the specific Windows-to-Windows Remote Control reproduction, missing sh evidence, and the remote launcher's POSIX assumption; it is not yet established whether those reports have the same cause.

Machine names, account/environment identifiers, private workspace paths, and conversation contents have been omitted. No complete diagnostic logs or session transcripts are attached.

Start in .vite/build/main-CMBCj4XL.js by tracing createRemoteTerminalBackend, Lle(), and the rejected process-session path, then follow exit/error handling in webview/assets/app-initial-f094ef01c64d.js and session listeners in webview/assets/terminal-panel-e2350b6eaef2.js. Reproduce with a remote Windows host that has PowerShell but no sh. Done means the terminal remains usable or displays an actionable startup failure, with regression coverage for both cases.