›_ Codex Issues
Codex Issues / #26779

Bug report: Codex mobile via ChatGPT mobile app remote Mac connection tries to run powershell.exe

Open 💬 7 comments Opened Jun 6, 2026 by Sankora
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

26.602.40724

What subscription do you have?

pro

What platform is your computer?

Darwin 25.4.0 arm64 arm

What issue are you seeing?

Bug report: Codex remote Mac connection tries to run powershell.exe

Summary

When connecting to a local macOS Codex host from the mobile/remote Codex flow, the connection fails with:

zsh:1: command not found: powershell.exe

This suggests the remote startup command is being generated as a Windows/PowerShell command even though the target host is macOS and the user's login shell is /bin/zsh.

Environment

  • Host OS: macOS 26.4.1, Apple Silicon
  • Codex app version: 26.602.40724
  • Bundled Codex CLI: codex-cli 0.137.0-alpha.4
  • Homebrew Codex CLI: codex-cli 0.136.0
  • Host display name in mobile UI: shion local
  • User login shell: /bin/zsh
  • Current shell: /bin/zsh
  • Date observed: 2026-06-06

Actual behavior

The mobile/remote Codex UI shows the host as disconnected/failed and displays:

zsh:1: command not found: powershell.exe

Expected behavior

For a macOS host, Codex should launch the remote command through the macOS login shell and should not attempt to execute powershell.exe.

Diagnostics already performed

  • Confirmed macOS account shell:

``text
shell: /bin/zsh
``

  • Confirmed current shell:

``text
/bin/zsh
``

  • Searched ~/.ssh, ~/.zshrc, ~/.zprofile, ~/.profile, ~/.bash_profile, and Codex config/application support files for powershell.exe; no relevant local configuration was found.
  • Checked ~/.ssh/authorized_keys; only a Gitea forced-command key was found, with no powershell.exe.
  • Checked Codex app state:

``text
remote_control_enrollments includes server_name=shion.local
``

No shell field or PowerShell command was found in that local table.

  • Checked Codex desktop logs. Relevant excerpt:

``text
[remote-connections/discovery] ssh_config_entrypoint_missing entrypointPath=/Users/shion/.ssh/config
``

  • Local SSH port 22 is reachable from the host, but local key authentication is not currently configured for self-SSH. That should not by itself cause powershell.exe to be selected on macOS.

Notes

The official Codex manual says SSH host connections are discovered from ~/.ssh/config and the remote Codex app server is started through the remote user's login shell. Since this host's login shell is /bin/zsh, the observed attempt to execute powershell.exe looks like either:

  • a stale remote/mobile host profile with Windows shell metadata, or
  • incorrect platform detection/default startup command generation for this macOS host.

Security/privacy

This report intentionally omits account IDs, tokens, keys, full paths to private files beyond standard config/log locations, and screenshots containing personal UI state.

What steps can reproduce the bug?

open ChatGPT mobile App
switch to codex tab
open settings and add a ssh connection
connect

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 1 month ago

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

  • #26164

Powered by Codex Action

Skyxim · 1 month ago

I am experiencing the same issue. It seems to be related to the default shell; as long as the default shell is not bash, it attempts to use powershell.exe. Both fish and zsh trigger this error, but after switching the default shell to bash, it connects successfully. No way, is Codex determining whether it is a connected Windows device based on bash?

paulnovacovici · 1 month ago
I am experiencing the same issue. It seems to be related to the default shell; as long as the default shell is not bash, it attempts to use powershell.exe. Both fish and zsh trigger this error, but after switching the default shell to bash, it connects successfully. No way, is Codex determining whether it is a connected Windows device based on bash?

Hmmm, I'm also getting this error but my default shell is bash

Skyxim · 1 month ago
> I am experiencing the same issue. It seems to be related to the default shell; as long as the default shell is not bash, it attempts to use powershell.exe. Both fish and zsh trigger this error, but after switching the default shell to bash, it connects successfully. No way, is Codex determining whether it is a connected Windows device based on bash? Hmmm, I'm also getting this error but my default shell is bash

This seems to be a misjudgment on my part. A newly created virtual machine (default bash) is able to connect. However, testing the unreachable computers today seems to confirm that it is ineffective.

Update:

Tested again today on a clean Linux environment with zsh as the default login shell, and Codex was able to connect successfully without the powershell.exe error. This strongly suggests that the problem on my other machines is caused by a conflict introduced by my dotfiles-managed shell setup (or some software/env variable pulled in by those dotfiles), rather than zsh itself or non-bash shells in general.

My next step will be to diff the clean environment against my usual dotfiles configuration to isolate which tool, script, or environment setting is causing Codex to try to launch powershell.exe on these hosts. I’ll add a minimal repro or specific conflicting component here once I track it down.

Skyxim · 1 month ago
> > I am experiencing the same issue. It seems to be related to the default shell; as long as the default shell is not bash, it attempts to use powershell.exe. Both fish and zsh trigger this error, but after switching the default shell to bash, it connects successfully. No way, is Codex determining whether it is a connected Windows device based on bash? > > > Hmmm, I'm also getting this error but my default shell is bash This seems to be a misjudgment on my part. A newly created virtual machine (default bash) is able to connect. However, testing the unreachable computers today seems to confirm that it is ineffective. Update: Tested again today on a clean Linux environment with zsh as the default login shell, and Codex was able to connect successfully without the powershell.exe error. This strongly suggests that the problem on my other machines is caused by a conflict introduced by my dotfiles-managed shell setup (or some software/env variable pulled in by those dotfiles), rather than zsh itself or non-bash shells in general. My next step will be to diff the clean environment against my usual dotfiles configuration to isolate which tool, script, or environment setting is causing Codex to try to launch powershell.exe on these hosts. I’ll add a minimal repro or specific conflicting component here once I track it down.

Investigation:

I tracked this down by progressively commenting out parts of my shell initialization and re-testing the Codex connection each time. By narrowing it step by step, I eventually found that as soon as the following line is executed:

echo -ne '\e[2 q'

the remote connection breaks and Codex can no longer start correctly. Although the UI shows a powershell.exe error, I suspect that’s just the last failing command Codex ends up trying after its startup protocol has already been confused by the unexpected escape sequence in the shell output.

Given this root cause, it’s probably worth double‑checking your shell initialization configs (‎.zshrc, ‎.bashrc, etc.) for anything that might interfere with a non‑interactive SSH shell, not just escape‑sequence ‎echo commands. In my case, a single line like:echo -ne '\e[2 q'.

Side note: it’s honestly quite frustrating that Codex doesn’t surface a clearer error in this situation—having it just collapse into a ‎powershell.exe command‑not‑found message makes the underlying problem much harder to diagnose.

roborule · 1 month ago
> > > I am experiencing the same issue. It seems to be related to the default shell; as long as the default shell is not bash, it attempts to use powershell.exe. Both fish and zsh trigger this error, but after switching the default shell to bash, it connects successfully. No way, is Codex determining whether it is a connected Windows device based on bash? > > > > > > Hmmm, I'm also getting this error but my default shell is bash > > This seems to be a misjudgment on my part. A newly created virtual machine (default bash) is able to connect. However, testing the unreachable computers today seems to confirm that it is ineffective. > > Update: > > Tested again today on a clean Linux environment with zsh as the default login shell, and Codex was able to connect successfully without the powershell.exe error. This strongly suggests that the problem on my other machines is caused by a conflict introduced by my dotfiles-managed shell setup (or some software/env variable pulled in by those dotfiles), rather than zsh itself or non-bash shells in general. > > My next step will be to diff the clean environment against my usual dotfiles configuration to isolate which tool, script, or environment setting is causing Codex to try to launch powershell.exe on these hosts. I’ll add a minimal repro or specific conflicting component here once I track it down. Investigation: I tracked this down by progressively commenting out parts of my shell initialization and re-testing the Codex connection each time. By narrowing it step by step, I eventually found that as soon as the following line is executed: ``sh echo -ne '\e[2 q' ` the remote connection breaks and Codex can no longer start correctly. Although the UI shows a powershell.exe error, I suspect that’s just the last failing command Codex ends up trying after its startup protocol has already been confused by the unexpected escape sequence in the shell output. Given this root cause, it’s probably worth double‑checking your shell initialization configs (‎.zshrc, ‎.bashrc, etc.) for anything that might interfere with a non‑interactive SSH shell, not just escape‑sequence ‎echo commands. In my case, a single line like:echo -ne '\e[2 q'. Side note: it’s honestly quite frustrating that Codex doesn’t surface a clearer error in this situation—having it just collapse into a ‎powershell.exe` command‑not‑found message makes the underlying problem much harder to diagnose.

Thank you for this. I was experiencing the same issue and this was the key clue for me.

I hit a very similar issue and confirmed it was shell startup output, not corrupted Codex state. In my case the culprit was Warp’s auto-warpify hook in .bashrc:

A part of the hook emits terminal control bytes on interactive shell startup. Codex remote startup seems to expect a clean stdout stream for its SSH/app-server handshake, so those bytes confused the protocol. The later powershell.exe error appears to be a misleading downstream/fallback symptom rather than the real root cause.

I fixed it by guarding the hook so it only runs for a real TTY/Warp session. After that, the Codex mobile connection worked fine for me.

Really appreciate the investigation. The powershell.exe error sent me in the wrong direction until your escape-sequence finding pointed at shell init output.

paulnovacovici · 1 month ago

Wow, thanks for the investigation! In my case neofetch was running on startup and writing to stdout which is crashing codex mobile. As soon as I guarded that from running codex mobile started working again