Mac Codex App remote SSH on shared Linux host attaches to another user's session / home directory

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

App itself as most recent, bundled codex version as codex-cli 0.122.0-alpha.1

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.3.0 arm64 arm

What issue are you seeing?

When I use the Mac Codex App to open a remote project over SSH on a shared Linux server, the app does not attach to my own remote account/session from my local ssh information.

Instead, the remote project picker defaults to another user's home directory. If I try to navigate to my actual home directory, the app shows "Unable to load folder contents: Permission denied (os error 13)"

If I create/open a remote project in the directory that the app defaults to, the integrated terminal inside that project reports that I am logged in as the other user, not as myself. i.e. cmd+J to open a terminal and whoami prints out not me but the default user's ID.

So this doesn't seem as a folder-picker issue; the app appears to be attaching to the wrong remote Codex runtime/session on the shared host.

What steps can reproduce the bug?

1. Use the Mac Codex App.
2. Configure a remote SSH connection to a shared Linux development host.
3. Ensure the host is multi-user.
4. In Codex App, choose "Add new project > Remote project"
5. Observe that the remote folder picker defaults to another user's home directory instead of mine.
6. Try navigating to my actual home directory (for example /home/myuser) and observe:

• Unable to load folder contents: Permission denied (os error 13)

1. If I open the defaulted remote project anyway and then open the integrated terminal, whoami reports the other user rather than my own ssh credentials.

What is the expected behavior?

Codex App should:

• attach only to the SSH-authenticated remote user
• browse that user's actual home/project directories
• never attach to another user's remote Codex runtime/session
• fail clearly if the remote app-server port or IPC path is already occupied, instead of silently attaching to the wrong target

Additional information

I verified the normal SSH path independently, and it is correct:

• normal SSH login lands me as my own user
• whoami over SSH is correct
• my passwd entry and home directory are correct
• my remote login shell PATH correctly resolves codex

I also checked the shared Linux host and found evidence that suggests cross-user collision:

• 127.0.0.1:9234 was already listening on the remote host
• /tmp/codex-ipc and related Codex temp artifacts were owned by another user on the shared machine

This seems related to the existing shared-host remote SSH port collision issue (issue #18503, #17227), but in my case the failure mode is worse: the Mac app appears to attach to another user's remote Codex environment rather than just failing cleanly.

On the remote server, the following diagnostic was ran,

ss -ltn | grep 9234
ls -ld /tmp/codex-ipc /tmp/codex-ipc-* /tmp/*codex* 2>/dev/null

with outputs of

LISTEN 0 4096 127.0.0.1:9234 0.0.0.0:*

and /tmp/codex-ipc, /tmp/codex-app-server-ssh-ws-v0.log being owned by different users.