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

[pminha]

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)
7. 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.

[github-actions]

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

• Windows Codex App remote connections fail when the remote machine's 127.0.0.1:9234 is already in use #18503
• VS Code Remote-SSH extension uses global /tmp/codex-ipc on multi-user Linux hosts, causing EACCES and cross-user IPC collisions #17765
• Reopen #3927: codex auth login fails with "Port 127.0.0.1:1455 is already in use" on WSL #17227

Powered by Codex Action

[tyx3211]

I would like to add: I also encountered the same issue on the Codex app for Windows.

My colleague and I tested this specific scenario. We are both using Windows machines and intended to use the Codex app to remotely connect to the same shared development machine (please note that we are two different users on the remote machine, and our SSH login accounts are different).

I logged in first. Since there was no application running on port 9234 on the remote machine at that time, I successfully connected. My colleague immediately prepared to connect. At this point, his remote Codex app-server failed to start due to a port collision, but his local Windows client ended up remotely connecting to my app-server.

As a result, my colleague was able to access all of my project sessions on the remote machine and could make the remote Codex do anything under my remote user permissions. My colleague could effectively grant the remote Codex full access under my identity.

This is extremely dangerous and much more severe than a standard port collision bug. It exposes the inadequacy of the entire authentication logic. For this type of SSH tunnel-based service, even if session-level tokens are not allocated (e.g., atomically creating them and setting permissions to 0600 under the ~/.codex/ directory), the service should implement user-level authentication mechanisms, similar to those used in yacd or zashboard. I hope this issue and the port collision problem will be fixed as soon as possible.