Codex App remote Windows project folder validation fails even though the folder exists
What version of the Codex App are you using (From “About Codex” dialog)?
26.506.31421
What subscription do you have?
Enterprise
What platform is your computer?
Local machine: Darwin 24.6.0 arm64 arm Remote host: Windows via OpenSSH_for_Windows_9.5
What issue are you seeing?
Codex App can connect to a Windows OpenSSH remote host using public-key authentication, but it rejects an existing remote project folder during "Add remote project".
The UI error is:
このリモートホスト上の既存のフォルダーを選択してください
SSH authentication succeeds:
Authenticated to <REMOTE_HOST> using "publickey".
The remote Codex CLI is available:
codex-cli 0.130.0
The target folder exists from the remote Windows Node.js runtime:
C:\Users\<REMOTE_USER>\<PROJECT_DIR> true
C:/Users/<REMOTE_USER>/<PROJECT_DIR> true
However, Codex App still rejects both path formats:
C:\Users\<REMOTE_USER>\<PROJECT_DIR>
C:/Users/<REMOTE_USER>/<PROJECT_DIR>
The remote app-server log repeatedly contains:
Error: app-server control socket is already in use at C:\Users\<REMOTE_USER>\.codex\app-server-control\app-server-control.sock
This appears to be a Windows remote app-server / folder validation issue rather than an SSH authentication or missing-folder issue.
What steps can reproduce the bug?
- On macOS, configure an SSH host in
~/.ssh/config:
Host <REMOTE_ALIAS>
HostName <REMOTE_HOST>
User <REMOTE_USER>
IdentityFile ~/.ssh/<PRIVATE_KEY>
IdentitiesOnly yes
AddKeysToAgent yes
UseKeychain yes
- Verify public-key SSH works from macOS:
ssh -o BatchMode=yes <REMOTE_ALIAS> exit
- On the Windows remote host, install Git Bash and configure Windows OpenSSH to use Git Bash as the default shell:
New-Item -Path "HKLM:\SOFTWARE\OpenSSH" -Force | Out-Null
New-ItemProperty `
-Path "HKLM:\SOFTWARE\OpenSSH" `
-Name DefaultShell `
-Value "C:\Program Files\Git\bin\bash.exe" `
-PropertyType String `
-Force
New-ItemProperty `
-Path "HKLM:\SOFTWARE\OpenSSH" `
-Name DefaultShellCommandOption `
-Value "-lc" `
-PropertyType String `
-Force
Restart-Service sshd
- Verify the remote shell and Codex CLI:
ssh <REMOTE_ALIAS> 'echo shell-ok; pwd; command -v sh; command -v codex; codex --version'
Example sanitized output:
shell-ok
/c/Users/<REMOTE_USER>
/usr/bin/sh
/c/Users/<REMOTE_USER>/AppData/Roaming/npm/codex
codex-cli 0.130.0
- Verify the target folder exists from the remote Node.js runtime:
ssh <REMOTE_ALIAS> 'node - <<'"'"'NODE'"'"'
const fs = require("fs");
for (const p of [
String.raw`C:\Users\<REMOTE_USER>\<PROJECT_DIR>`,
"C:/Users/<REMOTE_USER>/<PROJECT_DIR>"
]) {
const s = fs.statSync(p);
console.log(`${p}\t${s.isDirectory()}`);
}
NODE'
Example sanitized output:
C:\Users\<REMOTE_USER>\<PROJECT_DIR> true
C:/Users/<REMOTE_USER>/<PROJECT_DIR> true
- Open Codex App on macOS.
- Go to Settings > Connections.
- Add or enable the SSH host
<REMOTE_ALIAS>. - Try to add a remote project using either:
C:\Users\<REMOTE_USER>\<PROJECT_DIR>
or:
C:/Users/<REMOTE_USER>/<PROJECT_DIR>
- Codex App rejects the folder with:
このリモートホスト上の既存のフォルダーを選択してください
What is the expected behavior?
Codex App should accept the existing Windows remote folder and add it as a remote project.
If the remote app-server socket is stale, occupied, or otherwise unusable, Codex App should show a clear app-server/socket error and recover or restart the remote app-server, rather than reporting that the folder does not exist.
Additional information
Remote app-server log:
Error: app-server control socket is already in use at C:\Users\<REMOTE_USER>\.codex\app-server-control\app-server-control.sock
I tried:
- restarting Codex App
- deleting and re-adding the SSH remote host in Settings > Connections
- verifying SSH public-key authentication with
BatchMode=yes - verifying that the remote Codex CLI is available on
PATH - verifying that the target folder exists from the Windows Node.js runtime
- trying both backslash and forward-slash Windows path formats
- stopping stale remote Codex app-server processes
- deleting the stale app-server control socket
The issue still reproduces.
Related issues that seem similar but not identical:
I have intentionally redacted the real username, hostname, private IP address, key path, and project name.
2 Comments
I added a newer native-Windows repro with app-server/proxy live and ASAR/runtime details in #22965.
I can reproduce this on a newer Codex App build, and the failure is slightly stronger than the original report: the picker can browse into the folder and list its children, but still keeps the Add Project button disabled with the existing-folder error.
Environment:
26.519.81530on macOS26.5/ Darwin arm640.132.00.134.0OpenSSH_for_Windows_8.6, Windows10.0.22621.2283DefaultShell = C:\Program Files\Git\bin\bash.exeDefaultShellCommandOption = -lcObserved behavior:
Current reported app-server version: currentVersion=0.134.0Codex CLI initializedconnectedC:\IAA106\iaa-cms-devC:/IAA106/iaa-cms-dev``
text
``C:\Users\<user>\codex-projects\iaa-cms-dev -> C:\IAA106\iaa-cms-dev
.git,README.md, and project subdirectories.``
text
``请选择此远程主机上的现有文件夹。
Remote validation:
Remote Node.js also sees the folder and can list children:
Remote Codex CLI accepts the junction workdir as well:
The CLI starts and reports:
The command later fails due to account quota, but the workdir is accepted before model execution, so this is not a missing-folder problem.
Additional note:
C:\drive-root browsing is also fragile: the root contains Windows system/busy entries such asDumpStack.log.tmp,pagefile.sys, andswapfile.systhat throwEBUSYfrom Node stat calls. But the junction repro avoids that entirely and still fails, so the core bug appears to be the Add Remote Project validation/state path, not merely root directory listing.Expected behavior:
If
fs/readDirectory/folder browsing can show the directory contents and remote Node/Codex can stat/use the folder, the Add Project button should become enabled and the folder should be accepted. If there is another validation failure, the UI should surface the real validation error rather than saying the existing folder does not exist.